Bug 124443
| Summary: | Ordering of @INC makes upgrade of modules impossible | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Daniel Berrangé <berrange> | ||||
| Component: | perl | Assignee: | Jason Vas Dias <jvdias> | ||||
| Status: | CLOSED CANTFIX | QA Contact: | David Lawrence <dkl> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3.0 | CC: | chrismcc, dag, julien.tognazzi, pb | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2005-11-09 21:41:57 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
I've noticed that the Debian Perl packages are setup in a similar way to what I described above. Notes in their patch file: +Tweak @INC so that the ordering is: + + etc (for config files) + site (5.8.1) + vendor (all) + core (5.8.1) + site (version-indep) + site (pre-5.8.1) + +The rationale being that an admin (via site), or module packager +(vendor) can chose to shadow core modules when there is a newer +version than is included in core. http://http.us.debian.org/debian/pool/main/p/perl/perl_5.8.4-2.diff.gz I ran into this also. A good example is trying to install bugzilla. It needs newer versions of a coule perl mods. I can install them, but they won't get used. :( target for U3 ? same in perl-5.8.0-88.7 from RHEL3-U3beta Is anyone looking at this?
RHEL4 beta has the same problem
RHEL3:
Compiled at Jun 28 2004 14:32:58
@INC:
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
.
RHEL4:
@INC:
/usr/lib/perl5/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/5.8.5
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.5
/usr/lib/perl5/site_perl/5.8.4
/usr/lib/perl5/site_perl/5.8.3
/usr/lib/perl5/site_perl/5.8.2
/usr/lib/perl5/site_perl/5.8.1
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl/5.8.4
/usr/lib/perl5/vendor_perl/5.8.3
/usr/lib/perl5/vendor_perl/5.8.2
/usr/lib/perl5/vendor_perl/5.8.1
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl
.
chrismcc]$ perl -V
Compiled at Dec 15 2004 11:30:02
@INC:
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
.
Created attachment 108648 [details]
INC patch
patch basically stolen from freebsd ports http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/perl5.8/files/patch-perl.c http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/lang/perl5.8/files/patch-perl.c?rev=1.3&content-type=text/plain Is anyone looking at this bug?
MIME::QuotedPrint version 3.03 required--this is only version 2.03 at
/usr/lib/perl5/site_perl/5.8.0/MIME/Words.pm line 86.
rpm -qf
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/MIME/QuotedPrint.pm
perl-MIME-Base64-3.05
rpm -qf /usr/lib/perl5/5.8.0/i386-linux-thread-multi/MIME/QuotedPrint.pm
perl-5.8.0-88.9
:(
IMHO, changing every perl script to:
"use /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.5
/usr/lib/perl5/site_perl/5.8.4
/usr/lib/perl5/site_perl/5.8.3
/usr/lib/perl5/site_perl/5.8.2
/usr/lib/perl5/site_perl/5.8.1
/usr/lib/perl5/site_perl/5.8.0"
would be ... un-interesting.
unfortunately, changing this inside a RHEL release could potentially cause unexpected customer issues. however, I do agree that it needs fixed. it will be in future Fedora releases with the change to allow site_perl and vendor_perl to override core packages. yes this could cause potential problems. On the other hand it could
also solve many RedHat support issues.
contrived example:
customer: I'm installing $Package that we bought
It needs a new version of perl component $bar.
We installed with CPAN it but still perl "doesn't work"
RH support: Uh, add "use lib /usr/lib/perl5/site_perl" to every script.
customer: what's a script?, oh. you mean all 300 of them?
You might solve more problems switching it around. RH is in a better
position to judge support issues than I am and it is of course your call.
thanks either way. If worse comes to worse, I can patch it myself locally.
Unfortunately, this bug cannot be fixed in RHEL perl releases, now that we have done it this way we must continue. For RHEL releases, Red Hat undertakes to FULLY SUPPORT all the perl modules shipped as part of perl core. This undertaking would be impossible to fulfil if the site include path could override the perl core include path. Also, this could lead to many surprises for customers who, after installing a RHEL update, now find that all sorts of modules they'd forgotten about in their site perl include directories are now used instead of the perl core modules. Sorry - CANTFIX . I ran into the same issue by trying to use amavisd-new 2.3.3-1.1.el3.rf from Dag Wieers RPM repository. RHEL3's perl contains Digest::MD5 version 2.20 while amavisd-new now requires at least 2.22. I tried to supply a dedicated RPM package containing only a new Digest::MD5 module and installed it with --force. Interesting, that yum on a CentOS 3 version don't claim about afterwards, while up2date on a RHEL3 system suddenly reports: Name Version Rel ---------------------------------------------------------- perl 5.8.0 90.4 i386 Testing package set / solving RPM inter-dependencies... RPM package conflict error. The message was: Test install failed because of package conflicts: package perl-5.8.0-90.4 is already installed Would it be possible to upgrade at least the Digest::MD5 module in base package to 2.22 or has this minor version number also be stable for all RHEL releases? If yes, I submit a related bugzilla entry. BTW: what about a flag file (e.g. /etc/perl-remove-prepended-core-dir-from-INC) used by perl binary to change the behavior, if existing? Sure not a very good idea, but better than nothing. Fedora Core 5 shows:
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.7/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.8
/usr/lib/perl5/site_perl/5.8.7
/usr/lib/perl5/site_perl/5.8.6
/usr/lib/perl5/site_perl/5.8.5
/usr/lib/perl5/site_perl/5.8.4
/usr/lib/perl5/site_perl/5.8.3
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.8
/usr/lib/perl5/vendor_perl/5.8.7
/usr/lib/perl5/vendor_perl/5.8.6
/usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl/5.8.4
/usr/lib/perl5/vendor_perl/5.8.3
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/5.8.8
So hopefully RHEL5 would have fixed this problem, while in RHEL3 and RHEL4 it
would stay until end of usage :-(
BTW: as a workaround, I use now following for dedicated scripts:
# Remove base module path from @INC
shift @INC; shift @INC;
E.g. for amavisd from DAG repository:
--- /usr/sbin/amavisd.orig 2006-04-20 14:04:44.000000000 +0200
+++ /usr/sbin/amavisd 2006-04-20 14:12:42.000000000 +0200
@@ -137,6 +137,9 @@
}
BEGIN {
+ # Remove base module path from @INC
+ shift @INC; shift @INC;
+
fetch_modules('REQUIRED BASIC MODULES', 1, qw(
Exporter POSIX Fcntl Socket Errno Carp Time::HiRes
IO::Handle IO::File IO::Socket IO::Socket::UNIX IO::Socket::INET
|
Description of problem: The ordering of @INC in the perl binary contains the core directories /before/ the vendor & site directories: bash-2.05b$ perl -e 'print join("\n", @INC), "\n"' /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 bash-2.05b$ The result of this is that is it impossible to package, distribute & install newer versions of any of the modules within the core perl RPM. For example, the version of Net::FTP in the RHEL3 perl is 2.64, however, the latest on CPAN with 2.74. The only way I can upgrade in this scenario is to pass the INSTALLDIRS=perl argument to MakeMaker perl Makefile.PL INSTALLDIRS=perl which causes 'make install' to overrite the existing modules - of course this will get blown away next time 'up2date' pulls down a new perl errata. If you are trying to provide an RPM bundle containing this updated verion of Net::FTP this trick won't work at all because RPM obviously won't let 2 different packages install the same file. The solution to this is to simply ensure that paths listed in @INC are in the order 'site', 'vendor', 'perl': /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 NB, this is already the way it works on Debian for example. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Print out @INC 2. 3. Actual results: The core directories are listed before site & vendor directories. Expected results: The directories are in order site, vendor, then core. Additional info: