This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: perl vendorlib, sitelib


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]