From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8593 invoked by alias); 16 Aug 2014 07:00:22 -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 8543 invoked by uid 89); 16 Aug 2014 07:00:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-in-06.arcor-online.net Received: from mail-in-06.arcor-online.net (HELO mail-in-06.arcor-online.net) (151.189.21.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Sat, 16 Aug 2014 07:00:16 +0000 Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15]) by mx.arcor.de (Postfix) with ESMTP id 5B73210BE74 for ; Sat, 16 Aug 2014 09:00:13 +0200 (CEST) Received: from mail-in-14.arcor-online.net (mail-in-14.arcor-online.net [151.189.21.54]) by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id 6852C563214 for ; Sat, 16 Aug 2014 09:00:13 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-14.arcor-online.net 2667C9BE1C Received: from Rainer.invalid (pD9EB2EE8.dip0.t-ipconnect.de [217.235.46.232]) (Authenticated sender: stromeko@arcor.de) by mail-in-14.arcor-online.net (Postfix) with ESMTPSA id 2667C9BE1C for ; Sat, 16 Aug 2014 09:00:13 +0200 (CEST) From: Achim Gratz To: cygwin-apps@cygwin.com Subject: Re: perl-5.18.2-1 References: <534078A2.4000601@tiscali.co.uk> <87bnwf2cjl.fsf@Rainer.invalid> <534174C4.5010608@tiscali.co.uk> <87y4zi1kib.fsf@Rainer.invalid> <5341A3F5.2040506@tiscali.co.uk> <8761mlx7im.fsf@Rainer.invalid> <87a9bvsnse.fsf@Rainer.invalid> <8761loegk8.fsf_-_@Rainer.invalid> <87fvkq57do.fsf@Rainer.invalid> <87y4y8uoe2.fsf@Rainer.invalid> <87k369lc8v.fsf@Rainer.invalid> <1408137347.1564.19.camel@YAAKOV04> <53EE830D.1010008@tiscali.co.uk> Date: Sat, 16 Aug 2014 07:00:00 -0000 In-Reply-To: <53EE830D.1010008@tiscali.co.uk> (David Stacey's message of "Fri, 15 Aug 2014 23:00:45 +0100") Message-ID: <87zjf4ex6r.fsf@Rainer.invalid> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-08/txt/msg00100.txt.bz2 David Stacey writes: > Back in April, Reini expressed a desire to keep perl_vendor, claiming > that it is the easiest solution for both user and maintainer [1]. Well, I have been keeping a large local installation of Perl modules and without perl_vendor dissolved I can't maintain that. Some of the extra modules require newer versions of what is in perl_vendor. Now, for my local installation I create my own setup.ini files and I can simply patch things up whichever way I want, but that was a lot of effort to get there. That same problem is encountered by everyone else who tries to do something similar and the solution Reini suggests is that they install all their stuff via CPAN (which goes into site_perl and thus overrides vendor_perl). Guess what, I did exactly that at the beginning, but there were for instance problems with LWP that couldn't be resolved unless I removed it from vendor_perl. Also, I now have to install on machines that don't have access to CPAN (and I have only remote access to) so I must package the modules (which puts them into vendor_perl by default). Again, Reini suggests I mirror CPAN, but that is even more impractical. Even if I did, each update would consist of multiple steps, each of which could fail. > Whilst there are some of us who might question this, Reini has vastly > more knowledge and experience of perl than I ever will have. So when > Reini states that there are good reasons why perl_vendor should stay, > I am prepared to respect his judgement. I don't dispute that it might be good reasons for him. But I continue to say that for certain use cases (as the outlined above) this is a show stopper and requires a lot of effort to undo, which a lot of users would simply be unable to do and a bunch of others wouldn't have the time to spend on. I've already offered to do what's necessary since I already spent most of the work to make it happen. You can try out if it works for you (in a test installation if you want) by doing that 32bit install I pointed you at. We could then make an informed discussion on the way forward. > As our perl maintainer wishes to keep perl_vendor, any discussion to > the contrary seems somewhat academic. I respectfully disagree. The problems with that approach are real and just declaring that "nobody does this" is not going to make them go away. Anybody should be able to package any Perl distribution for Cygwin via cygport without having to dive into exactly how perl_vendor has been built. 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