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.