in reply to Distributing Perl in a Linux distribution

The core modules are either there because (mini)perl needs to run them to generate/compile the main perl executable, or they are there because they are considered to be essential to any Perl installation. There also are modules whose inclusion was a bad choice in retrospect, but a deprecation process has only slowly been started.

I think the appropriate way is to create your own RPM for the updated module and install the updated module in lib/site/, so that it gets found before the old version under lib/. In addition, I would ask this question on p5p, as currently, there is a discussion on how to restructure and reorder the Perl installation directories, which will affect you once you distribute 5.12.

Replies are listed 'Best First'.
Re^2: Distributing Perl in a Linux distribution
by gri6507 (Deacon) on Oct 01, 2009 at 13:14 UTC
    Thank you for the reply. The standalone RPMs for the core modules that I am talking about all deliver into lib/site, so our delivery/installation scheme is not a problem. However, I am a bit concerned about the future.

    Let me give you an example. Let's say I installed perl with its core modules into its standard built-in location. Then, I upgrade some module with a new version and place it into lib/site. Then, I upgrade perl itself to a new version with an even newer built-in version of that core module. Which version of the module would perl use then? I guess what I am asking is what's the search order of %INC?

    P.S. Thanks you for pointing me to the discussion about perl 5.12

[reply]
      perl -le "print for @INC"

      [download]

      will tell you the module search order for your perl executable.

      I guess that you will have to maintain the dependencies you introduce yourself, or at least take some precautions in your RPMs. I don't know if RPM has a "provides" rule so you can say:

      foo-2.0:
    #  this is your added package

perl-5.10.0:
    provides foo-1.0
    requires foo-2.0 # so that RPM also pulls in foo-2.0

perl-5.10.1:
    provides foo-3.0 # and RPM will automatically remove the foo-2.0 p
+ackage

      [download]

      But again, I think I wouldn't try to fudge around with the Perl distribution itself but create an enclosing package that pulls in the required separate RPMs:

      foo-2.0-meta:
    requires foo-2.0
    requires perl-5.10.0

      [download]

      That way, once you upgrade to foo-3.0, it could relax the requirement on the foo-2.0 package and RPM could remove it from the system.

[reply]
[d/l]
[select]
Re^2: Distributing Perl in a Linux distribution
by dolmen (Beadle) on Oct 01, 2009 at 14:57 UTC
    No, the right place for distribution-packaged modules is lib/vendor. lib/site is for module that the admin will install without packaging (either manually or using CPAN/CPANPLUS).
[reply]
[d/l]
[select]
      Correction :) 
      perl -V:installsitelib -V:installvendorlib

      [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom