From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122981 invoked by alias); 19 May 2017 18:36:04 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 122965 invoked by uid 89); 19 May 2017 18:36:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=majority, upgrades, minimizing, 5y X-HELO: mx009.vodafonemail.xion.oxcs.net Received: from mx009.vodafonemail.xion.oxcs.net (HELO mx009.vodafonemail.xion.oxcs.net) (153.92.174.39) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 May 2017 18:36:00 +0000 Received: from vsmx002.vodafonemail.xion.oxcs.net (unknown [192.168.75.192]) by mta-6-out.mta.xion.oxcs.net (Postfix) with ESMTP id 3DAB8D9B186 for ; Fri, 19 May 2017 18:36:01 +0000 (UTC) Received: from Gertrud (unknown [91.47.58.237]) by mta-6-out.mta.xion.oxcs.net (Postfix) with ESMTPA id ABF5719A9FA for ; Fri, 19 May 2017 18:35:58 +0000 (UTC) From: Achim Gratz To: cygwin-apps@cygwin.com Subject: Re: Perl layout for 5.26+ References: Date: Fri, 19 May 2017 18:36:00 -0000 In-Reply-To: (Yaakov Selkowitz's message of "Thu, 18 May 2017 15:39:00 -0500") Message-ID: <878tlsr8xi.fsf@Rainer.invalid> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-VADE-STATUS: LEGIT X-SW-Source: 2017-05/txt/msg00121.txt.bz2 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