On Thu, 2008-06-26 at 18:14 +0200, Stepan Kasal wrote:
> Hello all,
>
> there were recently some bugs considering the @INC path.
> (For the curious: bugs 448735 and 452898.)
>
> The current @INC contains long directory names. (I visited a Debian
> machine and it looked much saner.)
> I would like to understand the reasons.
>
> Let's imagine that @INC would be the following:
>
> /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
>
> What would be wrong if we switched to this simple layout?
Generally speaking, I think, your proposal is a step into the right
direction to clean up the mess having piled up :)
> More exactly:
> First, what would be wrong with this setup if it were used in a fresh new
> distribution?
I see 2 potential issues:
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. I am not aware of any such case, but I would not want to exclude
such case might exist.
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.
This doesn't seem consistent to me. My gut feeling is, both should be
versioned. Of cause one can argue, site-installs are a user's business
("you're on your own"), but ... I am ambivalent.
> And when the answer for the above is "nothing", then more
> questions come: Is it feasible to get to that setup in F-10? Which
> backward compatibility provisions should be done in order to ease the
> transition for Fedora users?
In addition to what Steve already wrote, 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).
Ralf
--
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
