This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: perl vendorlib, sitelib
- From: Achim Gratz <Stromeko at nexgo dot de>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 31 Jul 2015 21:33:12 +0200
- Subject: Re: perl vendorlib, sitelib
- Authentication-results: sourceware.org; auth=none
- References: <87pp3d1j22 dot fsf at Rainer dot invalid> <1aadral3rqdie0rlvu94knvju2htmd07ag at 4ax dot com> <1438369901 dot 17364 dot 18 dot camel at cygwin dot com>
Yaakov Selkowitz writes:
> This is a good point; pure Perl modules should not need to be rebuilt
> for every new Perl version.
As I've explained before, the impetus to rebuild even those is coming
from the large jump we're making with Perl for just this update, which
rolls up several user-visible and sometimes backwards-incompatible
changes, some of which have already completed the obsoletion cycle
between those versions and do not get warned about anymore.
> It's too late for 5.22, but for 5.24 could we change this to:
The next update will be 5.22.1 around September.
> prefix=/usr
> privlib=/usr/share/perl5/${VERSION%.*}
Why move that to /usr/share?
> archlib=/usr/lib/perl5/${VERSION%.*}
> vendorprefix=/usr
> vendorlib=/usr/share/perl5/vendor_perl
> vendorarch=/usr/lib/perl5/vendor_perl/${VERSION%.*}
That's not what openSUSE is doing, I haven't checked other Linux
distributions. I don't think it's a particularly good idea to conceal
which version of Perl the packaging was done with, since that's the only
way to inform any rebuild decisions for packages that haven't been
updated n a while. If we want to enable backwards compatibility we can
explicitly add the previous version of Perl to @INC like before; but as
said above I explicitly didn't want to do that for this update.
> siteprefix=/usr/local
> sitelib=/usr/local/share/perl5/site_perl
> sitearch=/usr/local/lib/perl5/site_perl/${VERSION%.*}
I see no problem moving site_perl to /usr/local, but I don't understand
what this is supposed to solve w.r.t. to packages using Perl modules.
> Besides being better compliant with FHS, this would help avoid
> unnecessary rebuilds with upgrades post-5.24. A similar change that I
> made to ruby for 2.0 saved me a LOT of time when upgrading to 2.2.
See above. Depending on what, if any backwards incompatible changes are
made between 5.22 and 5.24, the previous version (5.22) will be kept in
@INC. That means no immediate rebuilds will be necessary for that
update.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada