This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 2631 - /usr/lib/perl5/site_perl no longer in @INC
/usr/lib/perl5/site_perl no longer in @INC
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: perl (Show other bugs)
6.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Crutcher Dunnavant
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-05-07 07:29 EDT by nils
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-07-28 21:51:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description nils 1999-05-07 07:29:43 EDT
the perl package as shipped with RH6.0 no longer contains
/usr/lib/perl5/site_perl but /usr/lib/perl5/site_perl/5.005
as an include directory (@INC) which breaks many packages
which ship perl modules, e.g. gimp-1.1.5, the CPAN perl
modules (as of PowerTools 5.2) and so on.

/usr/lib/perl5/site_perl should always be in @INC otherwise
"foreign" packages (as the aforementioned ones) have to be
rebuilt with every new (major) perl version and have to be
clever enough to distinguish between perl versions that
search .../site_perl and versions that search
.../site_perl/{ver}
Comment 1 David Lawrence 1999-05-07 15:08:59 EDT
I have verified this to be true in 6.0 final.
Comment 2 joe 1999-05-23 05:17:59 EDT
Please, don't use such additional paths in @INC.

Perl has a clearly defined system for searching extensions,
patching it will sooner or later become a maintenance nightmare.
Better advise people to use the SRPMS.

------- Additional Comments From   05/23/99 09:12 -------
Then can someone of the perl wizards please explain why
/usr/lib/perl5/site_perl has been kicked out of @INC? Requiring each
and every perl package to be rebuilt after a minor (I consider
5.004 -> 5.005 as minor, you may not) perl upgrade (go ahead:
packages must "automagically" detect where to install the .pm's and
you have the mess of dynamically built file lists, ...) is to be
avoided. I'd rather have the nightmare of tweaking perl to look into
/usr/lib/perl5/site_perl again, thanks.
Comment 3 Cristian Gafton 1999-07-28 21:51:59 EDT
The change from 5.004 to 5.005 is anything but minor. It is binary
incompatible, as a matter of fact. I am not changing perl's default
@INC path because I can not fully understand all the things that will
break in the future if we do such a move now.

Note You need to log in before you can comment on or make changes to this bug.