What's the right @INC path?

[Ralf Corsepius]

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