Bug 448735 - Inconsistent @INC
Inconsistent @INC
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: perl (Show other bugs)
9
i386 Linux
low Severity low
: ---
: ---
Assigned To: Stepan Kasal
Fedora Extras Quality Assurance
:
: 449956 (view as bug list)
Depends On:
Blocks: 449956
  Show dependency treegraph
 
Reported: 2008-05-28 10:52 EDT by Paul Howarth
Modified: 2008-06-26 03:58 EDT (History)
7 users (show)

See Also:
Fixed In Version: 5.10.0-26.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-24 22:54:13 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)
typo fix (1.06 KB, patch)
2008-06-09 12:01 EDT, Stepan Kasal
no flags Details | Diff

  None (edit)
Description Paul Howarth 2008-05-28 10:52:16 EDT
perl on i386 has additional directories in @INC corresponding to old perl versions:

$ rpm -q perl
perl-5.10.0-20.fc9.i386
$ perl -V
Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.6.18-53.1.6.el5xen, archname=i386-linux-thread-multi
    uname='linux xenbuilder2.fedora.redhat.com 2.6.18-53.1.6.el5xen #1 smp wed
jan 16 04:10:44 est 2008 i686 i686 i386 gnulinux '
...
  @INC:
    /usr/lib/perl5/5.10.0/i386-linux-thread-multi
    /usr/lib/perl5/5.10.0
    /usr/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.10.0
    /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
    /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.10.0
    /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
    .

On x86_64, the same perl package release doesn't include the legacy directories:
$ rpm -q perl
perl-5.10.0-20.fc9.x86_64
$ perl -V
Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.6.18-53.1.6.el5xen, archname=x86_64-linux-thread-multi
    uname='linux xenbuilder4.fedora.phx.redhat.com 2.6.18-53.1.6.el5xen #1 smp
wed jan 16 04:10:44 est 2008 x86_64 x86_64 x86_64 gnulinux '
  @INC:
    /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi
    /usr/lib/perl5/5.10.0
    /usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi
    /usr/local/lib/perl5/site_perl/5.10.0
    /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.10.0
    /usr/lib/perl5/vendor_perl
    .

I believe the x86_64 configuration is the "correct" one; both versions have only
perl(:MODULE_COMPAT_5.10.0) provides.

A related issue is that a bunch of packages need rebuilding for perl 5.10 in
Fedora 9; they install modules in the 5.8.8 @INC directories, which currently
works on i386 but not x86_64. See Bug #448082 for details. Perhaps separate bugs
should be raised on all of those packages and tracked using this bug?
Comment 1 Paul Howarth 2008-05-29 05:11:58 EDT
perl-5.10.0-22.fc9 has the same issues.
Comment 2 Stepan Kasal 2008-05-29 07:57:37 EDT
Well, if I remove the empty directory /usr/lib/perl5/vendor_perl/5.8.7, then it
disappears from @INC.
I guess we should not deliberately break old third party modules, so we might
keep that as a candidate for the @INC, but should not pack the empty dirs to the
rpm.

The report also shows another inconsistency: on i386, site_perl is under
/usr/lib*, while on x86_64 it is under /usr/local/lib*.  Which is right?

Since our rpm's should install to vendor_perl, not site_perl, it would seem that
/usr/local/lib* is the right place for site_perl.  But we have to do something
about backward compatibility...  Would a symlink suffice?
Comment 3 Ralf Corsepius 2008-05-29 08:16:33 EDT
(In reply to comment #2)
> Well, if I remove the empty directory /usr/lib/perl5/vendor_perl/5.8.7, 
> then it disappears from @INC.
That's one half of the issue.

The real issue is
# rpm -q --provides perl | grep COMPAT
perl(:MODULE_COMPAT_5.10.0)

Note:  No COMPAT_5.8.* ....

=> You can't install packages, which rpm-wise 
Require perl(:MODULE_COMPAT_5.8...)

=> Though these package might be functional at run-time, these package are
broken rpm-wise.

> The report also shows another inconsistency: on i386, site_perl is under
> /usr/lib*, while on x86_64 it is under /usr/local/lib*.  Which is right?
>
 > Since our rpm's should install to vendor_perl, not site_perl, it would seem
> that /usr/local/lib* is the right place for site_perl.
How do other distros handle site_perl?

>  But we have to do something
> about backward compatibility...  Would a symlink suffice?
No way - never. /usr/local/lib* is not Fedora's business.

Fedora may set up perl's site_perl configuration to point to something below
/usr/local, but adding a symlink is no-no.

Comment 4 Stepan Kasal 2008-06-09 10:58:19 EDT
In reply to comment #3
> Note:  No COMPAT_5.8.*

Note that I mentioned third party modules, that supposedly do not have the
perl(:MODULE_COMPAT_5.x) require.
But I see no reason why they should use vedor_perl/5.8.x, not just vendor_perl,
so I agree with you that my argument was void.

> How do other distros handle site_perl?

A very quick look: I visited random debian machine, with perl 5.8.4, observing:
  @INC:
    /etc/perl
    /usr/local/lib/perl/5.8.4
    /usr/local/share/perl/5.8.4
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.8
    /usr/share/perl/5.8
    /usr/local/lib/site_perl
    .
Note: /usr/*/perl/5.8 is a symlink to the corresponding /usr/*/perl/5.8.4 .

I understand that only partially.  Unlike Fedora, the site_perl modules do not
override the vendor-supplied ones.  But there are those /usr/local/*/perl/5.8.4
special directories so that users have a way to override vendor-supplied perl
modules, if there is a real need.

But many aspects of this setup elude me:
- Why are the modules divided into lib and share, even for /usr/*/perl/5.8,
which is populated by the perl-base package?  Does that mean that the *.pm under
/usr/lib, though text files, are architecture dependent?
- Why is /usr/*/perl5 before the corresponding perl-base-populated directories?
 Does that imply that a module package can override modules provided by the core
perl package?  Is that desirable?

Since I'm puzzled, I can't get much from observing the Debian setup.
It looks inspiring to put site_perl near the end of @INC; but the request to
provide a site hook to override our modules would probably come immediately and
I'm not sure the change is worth all the hassle...
Comment 5 Stepan Kasal 2008-06-09 11:56:53 EDT
Add comment #4:
Debian has its own opinion, which seems to differ substatially from Perl upstream.
OTOH, Fedora is very close to upstream defaults; if you run ./Configure with
prefix=/usr, vendorprefix=/usr, siteprefix=/usr/local, you get a setup very
close to what we have.
Comment 6 Stepan Kasal 2008-06-09 12:01:47 EDT
Created attachment 308702 [details]
typo fix

First, there is an obvious typo---a misplaced %endif comments out several
arguments to ./Configure on all 32-bit platforms, which couldn't have been
intentional.  This is what the attached patch fixes.
Comment 7 Stepan Kasal 2008-06-09 12:06:36 EDT
More about site* defines in ./Configure, see also comment #5.

Why do we define siteprefix=/usr and then redefine sitelib and sitearch as if
siteprefix were /usr/local?  Wouldn't it be better to set siteprefix=/usr/local?
Yes, perl would then know that man pages can be also found under
/usr/local/share/man/man[13], but there is nothing wrong about it, right?
Comment 8 Fedora Update System 2008-06-12 07:35:56 EDT
perl-5.10.0-26.fc9 has been submitted as an update for Fedora 9
Comment 9 Paul Howarth 2008-06-12 09:38:29 EDT
So, to be clear, the updated package is only going to have 5.10.0 directories in
@INC, and drop the legacy ones, right?

If so, the next step should probably be to raise bugs on all packages that
currently install into 5.8.8 directories (which are already broken on x86_64 and
will soon be broken on i386 too), and also any that miss a dep on
perl(:MODULE_COMPAT_5.x) and hence may be missed by a dependency checker during
the next upgrade cycle.

Should we use this bug as a tracker for these new bugs?
Comment 10 Fedora Update System 2008-06-12 22:18:33 EDT
perl-5.10.0-26.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update perl'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-5256
Comment 11 Marcela Mašláňová 2008-06-13 05:19:40 EDT
*** Bug 449956 has been marked as a duplicate of this bug. ***
Comment 12 Fedora Update System 2008-06-24 22:54:06 EDT
perl-5.10.0-26.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 13 Stanis Trendelenburg 2008-06-25 18:43:39 EDT
perl-5.10.0-26.fc9 removed "/usr/lib/perl5/site_perl/5.10.0" from @INC, and
replaced it with "/usr/local/lib/perl5/site_perl/5.10.0".

This update breaks *every* Perl program that relies on *any* CPAN module
installed prior to this update, because all of those modules have been installed
under the old "site_perl" directory and are now out of the search path!

Please re-add /usr/lib/perl5/site_perl/5.10.0 in the next update. As a
workaroud, symlink /usr/local/lib/perl5/site_perl/5.10.0 to
/usr/lib/site_perl/5.10.0
Comment 14 Stepan Kasal 2008-06-26 03:50:48 EDT
(In reply to comment #13)
> perl-5.10.0-26.fc9 removed "/usr/lib/perl5/site_perl/5.10.0" from @INC, and
> replaced it with "/usr/local/lib/perl5/site_perl/5.10.0".
> 
> This update breaks *every* Perl program that relies on *any* CPAN module
> installed prior to this update, [...]

Let me add that this is true for 32bit systems only.  On 64bit systems,
site_perl is under /usr/local since the update to 5.10.0, i.e. since the release
of Fedora 9.

But yes, we may add /usr/lib/.../site_path to @INC for backward compatibility,
at least on 32 bit systems.  That will delay the surprise until upgrade to
Fedora 10, where it can be more expected.  ;-)
Comment 15 Stepan Kasal 2008-06-26 03:58:50 EDT
I keep this bug closed, as the @INC paths are consistent in the moment.  Bug
#452898 has been filed to track the backward compatibility bug.

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