Perl layout for 5.26+
Yaakov Selkowitz
yselkowitz@cygwin.com
Thu May 18 20:39:00 GMT 2017
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
More information about the Cygwin-apps
mailing list