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