Bug 508504 - system perl shouldnt use /usr/local/
system perl shouldnt use /usr/local/
Product: Fedora
Classification: Fedora
Component: perl (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Stepan Kasal
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-06-27 20:33 EDT by Jim Cromie
Modified: 2009-07-09 05:15 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-07 17:40:57 EDT
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 Jim Cromie 2009-06-27 20:33:01 EDT
Description of problem:

perl's INC now includes /usr/local, which seems exactly wrong for the system perl.


most paths are /usr/lib/perl5, which is expected, and how it was for all of
5.8.* releases.

Version-Release number of selected component (if applicable):
$> rpm -q perl

How reproducible:


Steps to Reproduce:
1. perl -V
2. look at bottom of output
Actual results:

see above

Expected results:

previous releases stayed in /usr/lib,

Additional info:

While not strictly speaking wrong, it seems unwise, since folks who
will build their own perl from sources will typically use /usr/local,
expecting it to be non-interfering with their system perl.

If their perl is close enough (apparent XS compatibility)
but with minor -D<Defines> different, they could get linkage
failures etc, and blame it on interference by the system perl.

And you have vendor_perl already, it seems enough to cover your needs.

The mitigating factor here is that self-built perls usually wont
have -i386 in the XS paths, but something like -i686 or better,
preventing (for now) the un-planned sharing of binary/XS INC paths.
Comment 1 Jim Cromie 2009-06-27 20:51:44 EDT
FTR, heres an older RH/Fedora build..

# perl -V
Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
   osname=linux, osvers=2.6.9-22.18.bz155725.elsmp, archname=i386-linux-thread-multi
   uname='linux hs20-bc1-4.build.redhat.com 2.6.9-22.18.bz155725.elsmp #1 smp thu nov 17 15:34:08 est 2005 i686 i686 i386 gnulinux '
   config_args='-des -Doptimize=-O2 -g -pipe -m32 -march=i686 -mtune=nocona -Dversion=5.8.5 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dinc_version_list=5.8.4 5.8.3 5.8.2 5.8.1 5.8.0'
   hint=recommended, useposix=true, d_sigaction=define
   usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
   useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
   use64bitint=undef use64bitall=undef uselongdouble=undef
   usemymalloc=n, bincompat5005=undef
   cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
   optimize='-O2 -g -pipe -m32 -march=i686 -mtune=nocona',
   cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm'
   ccversion='', gccversion='3.4.6 20060404 (Red Hat 3.4.6-2)', gccosandvers=''
   intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
   d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
   ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
   alignbytes=4, prototype=define
 Linker and Libraries:
   ld='gcc', ldflags =' -L/usr/local/lib'
   libpth=/usr/local/lib /lib /usr/lib
   libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
   perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
   libc=/lib/libc-2.3.4.so, so=so, useshrplib=true, libperl=libperl.so
 Dynamic Linking:
   dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE'
   cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Characteristics of this binary (from libperl):
 Built under linux
 Compiled at Jul 24 2006 18:28:10
Comment 2 Jim Cromie 2009-07-07 17:40:57 EDT
p5p has no problem with fedora choices,
I doubt I'll get caught by this, and if so, not for long.
Im closing..
Comment 3 Stepan Kasal 2009-07-09 05:15:03 EDT
Indeed, searching for additional modules under /usr/local/something is similar to the fact that PATH contains /usr/local/bin.
But the /usr/local tree is totally under the control of the site administrator, no Fedora rpm package will install anything into it.

Please note that perl's sitelib and sitearch directories must actually go somewhere under /usr/local, as they are a site specific.

If you install a module directly from cpan, it should go to sitelib and sitearch.
OTOH, when you install a module from a Fedora repository, e.g. by yum, it goes to vendorlib/vendorarch.

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