develooper Front page | perl.perl5.porters | Postings from July 2002

Re: order of @INC

Thread Previous | Thread Next
From:
Chip Turner
Date:
July 17, 2002 05:47
Subject:
Re: order of @INC
Message ID:
vzk7kjucyij.fsf@minbar.devel.redhat.com
Michael G Schwern <schwern@pobox.com> writes:

> On Mon, Jun 24, 2002 at 02:33:00PM +0100, Nick Ing-Simmons wrote:
> > Arthur Bergman <arthur@contiller.se> writes:
> > >Why is @INC ordered this way?
> > >     /usr/local/lib/perl5/5.6.1/i686-linux-thread-multi
> > >     /usr/local/lib/perl5/5.6.1
> > >     /usr/local/lib/perl5/site_perl/5.6.1/i686-linux-thread-multi
> > >     /usr/local/lib/perl5/site_perl/5.6.1
> > >
> > >With the core location before site_perl?
> > 
> > So that a freshly installed perl is not poluted by old versions
> > of modules (which are now in core) which happen to be in site_perl.
> 
> Isn't that what the version number after site_perl is there to prevent?
> 
> As a point of order, it should be noted that both Redhat and Debian reverse
> the above order in their versions so that CPAN modules installed will
> override the core.  Actually, the problem is deeper and only partially
> solved with vendor directories because there's actually three sets of
> modules.
> 
> 	1. Core
> 	2. From an rpm/dpkg
> 	3. Directly from CPAN
> 
> See http://www.debian.org/doc/packaging-manuals/perl-policy/ for details.

As a followup, Red Hat's INC ordering has changed in 7.3 and in
Rawhide (our cutting edge release where we put code in testing).  RH
7.3 shipped with perl 5.6.1 with the following @INC:

    /usr/lib/perl5/5.6.1/i386-linux
    /usr/lib/perl5/5.6.1
    /usr/lib/perl5/site_perl/5.6.1/i386-linux
    /usr/lib/perl5/site_perl/5.6.1
    /usr/lib/perl5/site_perl/5.6.0/i386-linux
    /usr/lib/perl5/site_perl/5.6.0
    /usr/lib/perl5/site_perl
    /usr/lib/perl5/vendor_perl/5.6.1/i386-linux
    /usr/lib/perl5/vendor_perl/5.6.1
    /usr/lib/perl5/vendor_perl
    .

The idea here is that all Red Hat perl modules install into
vendor_perl, allowing users to override our packaging by installing
their own modules, which will default to site_perl.  Likewise, we did
the same with Rawhide, though using perl 5.8.0.

It would be very, very nice to have an @INC come -before- core
perl's.  This would allow someone to install the latest libnet, for
example; in six months, it is almost certain every package perl ships
with will be older than what is available on CPAN.  From a packaging
perspective, Red Hat's RPM packaging system can't override a file from
package A with a different file from a later package B.  This means we
can't replace, say, CPAN.pm in place; we would have to upgrade perl
itself.  Right now, we split perl into a few sub-packages (perl,
perl-CGI, perl-CPAN, perl-DB_File), with more perhaps coming later.
This way, we -can- upgrade those individual packages, if need be.
This technique of vendor_perl basically was copied from Debian.

I am considering changing @INC a bit so that core packages come after
site_perl, but I'd rather not move away from the standard, upstream
ordering, if possible.  I think, though, that some better control over
@INC ordering is necessary to make perl easier to package.

Another oddity is perl 5.8.0's configure will throw 5.6.1 directories
into @INC if it sees there may be modules there.  This seems flawed,
however, since it basically means 5.8.0 is trying to "help" by finding
old @INC paths, but likely won't work if there are modules that
contain or require other modules with XS components.

Chip

-- 
Chip Turner                   cturner@redhat.com
                              Red Hat, Inc.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About