This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Perl layout for 5.26+
- From: Yaakov Selkowitz <yselkowitz at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 18 May 2017 15:39:00 -0500
- Subject: Perl layout for 5.26+
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=cygwin.com
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=none smtp.mailfrom=yselkowitz at cygwin dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 26516CED8
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 26516CED8
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