What's the right @INC path?

Stepan Kasal skasal at redhat.com
Fri Jun 27 10:10:29 UTC 2008


Hello Ralf,

On Fri, Jun 27, 2008 at 08:42:07AM +0200, Ralf Corsepius wrote:
> On Thu, 2008-06-26 at 18:14 +0200, Stepan Kasal wrote:
> > /usr/lib/perl5/5.10.0	-Darchlib=%{_libdir}/perl5/%{perl_version}
> > /usr/share/perl5/5.10.0	-Dprivlib=%{_prefix}/share/perl5/%{perl_version}
> > /usr/local/lib/perl5	-Dsitearch=%{_prefix}/local/%{_lib}/perl5
> > /usr/local/share/perl5	-Dsitelib=%{_prefix}/local/share/perl5
> > /usr/lib/perl5		-Dvendorarch=%{_libdir}/perl5
> > /usr/share/perl5	-Dvendorlib=%{_prefix}/share/perl5

> 1. You seem to be wanting to strip off the $archname part from paths.
> I am not sure if this won't cause clashes between noarch'ed and arch'ed
> files.

Please note that the arch directories are not the same as the noarch
ones.  For example the vendor arch dir on x86_64 would be
/usr/lib64/perl while the corresponding noarch one would be
/usr/share/perl5.

> 2. So far, both, site- and vendor-libdirs have been versioned.
> With your proposal, the "site"-directories become unversioned, while the
> "vendor"-directories remain versioned.

Note that the "vendor" directories are not versioned either, e.g.,
the vendor noarch directory is /usr/share/perl5.

The versioned subdirectories are the "private" ones, which should be
populated exlusively by rpms built from perl.src.rpm.  All these
should change as soon as perl itself is updated.

> [...] perl-module/dist-rpms having
> been built before and after this change, rpm-wise would still carry the
> same  "Requires: perl(:MODULE_COMPAT_*)"
> 
> I.e. rpm-wise, though this change would break module search path
> compatibility, it would not be detectable through rpm.
> A complete rebuild of anything perl-related probably would solve this
> inside of Fedora, but this doesn't help those users who install
> additional perl-modules through rpms (which e.g. I do).

Thank you very much for poiting this out, I have forgotten about it.

But note that I did already break this rpm compatibility two weeks
ago for 32bit platforms, in perl-5.10.0-26.fc10 (see below for
details).  Unless we decide to repair this breakage now, we can as
well use the oportunity and do another breakage now, this time for
all platforms.  :-P 

OTOH, we could add the old style paths to @INC and carry them for
backward compatibility until the "perl(:MODULE_COMPAT_*)" require
changes.

Have a nice day,
	Stepan

Appendix:
How I broke 32bit perl rpm-wise recently in rawhide

While trying to fix bug 448735, I discovered that perl.spec contained
a typo, an "%ifarch multilib64" governed more Configure parameters
than it should, and I just removed the typo.  That would have been
fine _before_ 5.10 went main stream, but it was a mistake now.

This generated a compatibility problem, reported as #452898.
I hacked F-9/perl.spec to improve backward compatibility, but rawhide
remains as it is.
I guess this means that rawhide on 32bit archs is broken rpm-wise.
IMVHO, it's not worth it to add the compatibility paths to rawhide,
though.




More information about the Fedora-perl-devel-list mailing list