Perl layout for 5.26+

Perl layout for 5.26+

[Yaakov Selkowitz]

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.  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).

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.

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.

-- 
Yaakov

Re: Perl layout for 5.26+

[Achim Gratz]

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

Re: Perl layout for 5.26+

[Achim Gratz]

Yaakov Selkowitz writes:
> 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.

Also, why do you propose to drop archname from the *arch directories?
This would make it impossible to put these on shared drives, so I'm
more inclined to leave these as they were.

	prefix="/usr"
	siteprefix="/usr/local"
	vendorprefix="/usr"

	vendorman1dir="${vendorprefix}/share/man/man1"
	vendorman3dir="${vendorprefix}/share/man/man3"
	html1dir="${prefix}/share/doc/perl/html/html1"
	html3dir="${prefix}/share/doc/perl/html/html3"
	sitehtml1dir="${siteprefix}/share/doc/perl/html/html1"
	sitehtml3dir="${siteprefix}/share/doc/perl/html/html3"
	vendorhtml1dir="${vendorprefix}/share/doc/perl/html/html1"
	vendorhtml3dir="${vendorprefix}/share/doc/perl/html/html3"

	archname=${ARCHNAME}
	privlib="${prefix}/share/perl5/${PERLV}"
	sitelib="${siteprefix}/share/perl5/site_perl/${PERLV}"
	vendorlib="${vendorprefix}/lib/perl5/vendor_perl/${PERLV}"
	archlib="${prefix}/lib/perl5/${PERLV}/${ARCHNAME}"
	sitearch="${siteprefix}/lib/perl5/vendor_perl/${PERLV}/${ARCHNAME}"
	vendorarch="${vendorprefix}/lib/perl5/site_perl/${PERLV}/${ARCHNAME}"

	sitebin="${siteprefix}/bin"
	sitescript="${siteprefix}/bin"

I would also leave the versioning on the noarch dirs.  We need to do a
full rebuild for 5.26 anyway and for 5.28 we can just as easily include
the previous version of the noarch directories in @INC if that is known
to work just like we did between 5.10 and 5.14.


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds