Re: Perl layout for 5.26+

[Achim Gratz <Stromeko@nexgo.de>]

Yaakov Selkowitz writes:
> With the upgrade to 5.26, we will need to rebuild every single Perl
> module package again.  While we have no choice for 5.26, I would like
> to implement a method of minimizing the effort that will be needed in
> future upgrades.
>
> For 5.22 we had:
>
> prefix=/usr
> privlib=/usr/lib/perl5/$slot
> archlib=/usr/lib/perl5/5.22/$archname
> vendorlib=/usr/lib/perl5/vendor_perl/5.22
> vendorarch=/usr/lib/perl5/vendor_perl/5.22/$archname
> sitelib=/usr/lib/perl5/site_perl/5.22
> sitearch=/usr/lib/perl5/site_perl/5.22/$archname
>
> Instead, we should switch to:
>
> prefix=/usr
> privlib=/usr/share/perl5/5.26
> archlib=/usr/lib/perl5/5.26
> vendorprefix=/usr
> vendorlib=/usr/share/perl5/vendor_perl
> vendorarch=/usr/lib/perl5/vendor_perl/5.26
> siteprefix=/usr/local
> sitelib=/usr/local/share/perl5
> sitearch=/usr/local/lib/perl5/5.26
>
> By un-versioning privlib/vendorlib/sitelib, it will no longer be
> necessary to rebuild noarch Perl module packages -- which are the
> large majority (~70%) -- with every single 5.Y release of Perl.

That may or may not work, depending on what exactly gets moved into or
out of core between the two versions.  It ususally isn't a problem, but
for exactly this reason most distros using "unversioned" noarch
directories actually provide a versioned one as well.  Debian has an
especially complicated layout of:

    /usr/share/perl5
    /usr/share/perl/5.xy

with the latter part containing the core libs I suppose.  This may be
unavoidable if you cater for installation of multiple independent
version of Perl, but I'd not want to go there for Cygwin.  Debian also
has a braindead search order IMHO with the /usr/local part taking
precedence for archful / versioned and taking last place for sitelib.

> In other words, if we do this for 5.26, then for 5.28+ only ~110
> packages will need to be rebuilt instead of ~350 (besides those which
> link against libperl but do not install anything into any of those
> locations).

Besides tying up the machine cycles I really have no a problem with that
rebuild and there is only a handful of packages left that I don't at
least co-maintain, so I'd not use that argument for any decision.

> Using lib for archful things vs. share for noarch, and /usr/local for
> site*, is for compliance with FHS, and the latter avoids a lot of
> confusion over which should be used by packages.

The sitelib I don't really care about (users on Cygwin should almost
always use local::lib instead) and putting it in /usr/local is no
problem I think (might even be helpful in cases where /usr/local is
writable by users, but not /usr/lib).  Putting the noarch stuff into
/usr/share is done on some GNU/Linux distros and not on others, so
there's precedent either way.

> I implemented a similar scheme for Ruby, which makes it *much* easier
> to upgrade to new versions thereof.  Fedora does something similar, so
> there is plenty of precedent for such a move.

I'm not too fond of the idea of /usr/share/perl myself as it's yet
another path prefix you need to search in, but I don't really feel
strongly about it.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves