in reply to Re: Wow! Painful upgrade to Perl 5.12
in thread Wow! Painful upgrade to Perl 5.12

I have installed Perl 5.10 via FreeBSD Ports & modules that I use (system wide). Few days ago I also installed Perl 5.12 RC2 in my own user directory. After installing a module (and optional dependecies) not availble yet via FreeBSD ports with perl 5.12, I was thinking of installing pure perl modules in a tree separate from the ones which need to be compiled.

Point would be to share pure perl modules as much as possible, and avoid duplicate or reinstall among various perl versions as far as possible. My query in that regard is is there a way to distinguish a module (between a pure perl or compiled one) via cpan(plus) or during "perl (MakeFile|Build).pl .. (make|Build) install"?

Having different trees might not work out too well while automatically installing witin cpan(plus) as the initial tree might be set to the appropriate type based on the primary module, but not for subsequent dependencies. Seems like, cpan itself would need to be changed to accommodate the scenario.

If there are other suggestions to have separate version independent trees (of pure perl modules in one, compiled, version specific in another), I am all ears.

  • Comment on Re^2: Wow! Painful upgrade to Perl 5.12

Replies are listed 'Best First'.
Re^3: Wow! Painful upgrade to Perl 5.12
by ikegami (Patriarch) on May 19, 2010 at 20:03 UTC

    I was thinking of installing pure perl modules in a tree separate from the ones which need to be compiled.

    You can instruct Perl's builder to add the lib directories of other Perl installations to the list from which @INC is initialised. Pure Perl modules will work fine, XS modules will give an error.

[reply]
Re^3: Wow! Painful upgrade to Perl 5.12
by chromatic (Archbishop) on May 19, 2010 at 17:22 UTC
    Point would be to share pure perl modules as much as possible, and avoid duplicate or reinstall among various perl versions as far as possible.

    How do you know those pure Perl modules have no XS dependencies, and how do you know those pure Perl modules and their dependencies work unmodified on newer versions of Perl 5?

[reply]

      I personally care about only of those pure perl (call it "pp") modules which would continue to work with changing supporting software to a large extent, barring API changes. I am under no illusion that pp modules would not need to be ever updated to follow supporting software. If a otherwise pp module follows very closely changes in supporting modules, then it could go in the "perl-verison" directory along with rest of the lot.

      Those concern are for later|never term, for me; I still do not know how to differentiate module type programmatically.

      Putting the issue other way, would this be workable (to avoid manual work of module installation via any method among package manager, cpan, "perl Makefile.PL", etc.) ...

      • programmatically generate list of modules in old version;
      • install new perl;
      • programmatically generate difference list from modules in new perl (in core, I suppose) & previous list;
      • install modules from the difference list

      ... ?

[reply]

        CPAN has an autobundle command for that purpose.

[reply]
[d/l]
Re^3: Wow! Painful upgrade to Perl 5.12
by JavaFan (Canon) on May 19, 2010 at 14:33 UTC
    Modules that aren't part of the core system are (unless overridden) installed in $LIBDIR/site_perl/<perl-version>/. Vendor (Linux distros for instances) supplied modules ought to go into $LIBDIR/vendor/<perl-version>. Core modules go into $LIBDIR/<perl-version>.
[reply]
[d/l]
[select]
      (I should have noted that I understand the default directory tree structure.) Yes, that <perl-version> is what I am trying to avoid, so that when 5.13 would come around, 5.12 directory would be blown away & pure perl modules remain unaffected installed outside of <perl-version> directory.
[reply]
[d/l]
[select]
        Possible. Just give it the appropriate configuration options when compiling Perl. I'd guess the appropriate options are mentioned and described in the INSTALL that comes with the core tarball.

        If you get your Perl from a third-party vendor (ActiveState, RedHat, ...), you should talk to them and see if they'll compile one for you.

        Having said that, what ought to work (but I won't make any promises) is: 

        $ rm -rf $LIBDIR/site_perl/<old-perl-version>/<archdir>
$ mv $LIBDIR/site_perl/<old-perl-version> $LIBDIR/site_perl/<new-perl-
+version>

        [download]
[reply]
[d/l]

In Section Meditations