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.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
