Re^2: Distributing Perl in a Linux distribution

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

Comment on Re^2: Distributing Perl in a Linux distribution

Replies are listed 'Best First'.

Re^3: Distributing Perl in a Linux distribution
by Corion (Patriarch) on Oct 01, 2009 at 13:23 UTC

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]


Perl: the Markov chain saw
	PerlMonks