Bug 178688
| Summary: | Poor choice of build option -Dinc_version_list | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Jerrad Pierce <belg4mit> |
| Component: | perl | Assignee: | Jason Vas Dias <jvdias> |
| Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | prockai |
| 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: | 2006-01-24 00:35:36 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: | |||
|
Description
Jerrad Pierce
2006-01-23 15:24:45 UTC
Sorry, but we undertake to support modules for every perl version in each
RHEL version, particularly in supporting upgrade from RHEL-3 (perl-5.8.0) -
a perl module installed under RHEL-3 must still work after upgrade to RHEL-4 .
Startup time consumed by module search path searches can be minimised by
placing 'BEGIN { @INC=...; }' in perl scripts that require a fast startup time.
If you're sure you have no modules under unused perl version directories, remove
those directories. The time taken for module search patch traversal is in any
case minimal. So this is being closed as 'NOTABUG'.
And yet upgraded users could set @INC explicitly as you would have non-legacy users do, or use the inherent legacy support option I listed of PERL5LIB. "Removing directories" is a no-op because these directories don't exist, but are still in the binary's @INC. The question is not of the *perl module* working, that's nonsensical, but of the code which uses it being able to find the module. The time is *not trivial*, see the aforementioned article, or recent thread on the DateTime mailing list. And there is also the other issue of message dumping. If you are still so eager to dismiss this as NOTABUG (I agree, it's not, it's a poor implementation decision... exacerbated by some unfortunate choices in perl's handling of @INC) then *at least* pay attention and do not do this when RHEL ends up using perl 5.8.7 or later. In that case, if you still will not use PERL5LIB, make use of sitecustomize.pl which is user customizable; at which point the package preinstall scripts ought to check for existance of old site_perl and Do The Right Thing. Because perl -Mnonesuch Can't locate nonesuch.pm in @INC (@INC contains: /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 .). BEGIN failed--compilation aborted. Is too much spew. |