perl-5.10.0-22.fc9 has the same issues.

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?

(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.

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...

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.

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.

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?

perl-5.10.0-26.fc9 has been submitted as an update for Fedora 9

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?

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

*** Bug 449956 has been marked as a duplicate of this bug. ***

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.

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

(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.  ;-)

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.