Bug 56348 - site_perl at end of @INC creates dependency problems
site_perl at end of @INC creates dependency problems
Product: Red Hat Linux
Classification: Retired
Component: perl (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chip Turner
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-11-15 17:52 EST by Rich Lafferty
Modified: 2007-04-18 12:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-02-22 10:32:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rich Lafferty 2001-11-15 17:52:13 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-22 i686)

Description of problem:
Since @INC contains the standard include directories before the
site_perl ones, newer versions of modules installed into site_perl
aren't used (since the older version shipped with Perl is encountered
first). This leads to difficult-to-resolve dependency problems, since
installing a newer version of the module requires either overwriting or
removing the version of the module that shipped with Perl.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. perl -V


Actual Results:      /usr/lib/perl5/5.6.0/i386-linux

Expected Results:      /usr/lib/perl5/site_perl/5.6.0/i386-linux

Additional info:
Comment 1 Rich Lafferty 2002-02-22 10:32:27 EST
Hrm, this doesn't work. I'll use Getopt::Long as an example; let's say that
you have a program "foo" installed via RPM that depends on the Getopt::Long
shipped with perl, and another program "bar" that requires a newer version of 

The new version of Getopt::Long would have to be installed into site_perl if
installed via RPM, otherwise it would conflict with perl. The way I originally
thought about this is that because of that conflict, site_perl needs to be
first, so that "bar" will find the library it needs.

But that breaks "foo", and the only way that "foo" can require a particular
version of Getopt::Long is to depend on the correct perl rpm. If site_perl
is first in @INC, depending on the perl rpm isn't reliable for module
versions anymore.

It seems to me that the only way to solve this is to compartmentalize
the perl packages more, so that instead of depending on perl, "foo" would
depend on perl-Getopt-Long, and then you could upgrade perl-Getopt-Long, 
and foo would either be content or complain when you tried.

Peter Jones mentioned that you were considering a sysadmin-configurable
@INC; I'm not sure that's a solution either, because it'll still break
dependencies in the same way as universally changing @INC. Of course,
setting $PERL5LIB does the same thing, but since it's user-by-user, I
think $PERL5LIB is a reasonable "if it breaks, you get both pieces" case
that can be ignored.

This is not to say that I *expect* the perl rpm to be broken up into its
components, but I'm not sure that there's another solution that's more
graceful/effective than just saying "If you want it to behave differently,
set $PERL5LIB, or 'use lib'".

I've no idea if this makes sense written out, but it makes sense to me! :-)
Comment 2 Chip Turner 2002-04-10 20:24:32 EDT
the perl in the latest skipjack beta should have @INC now split.  we've moved
all of our modules to the vendor_perl tree, which comes after site_perl in @INC:


This should solve the problem you see.

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