This is the mail archive of the
mailing list for the Cygwin project.
- From: Achim Gratz <Stromeko at nexgo dot de>
- To: cygwin-apps at cygwin dot com
- Date: Sat, 16 Aug 2014 09:00:12 +0200
- Subject: Re: perl-5.18.2-1
- Authentication-results: sourceware.org; auth=none
- References: <534078A2 dot 4000601 at tiscali dot co dot uk> <87bnwf2cjl dot fsf at Rainer dot invalid> <534174C4 dot 5010608 at tiscali dot co dot uk> <87y4zi1kib dot fsf at Rainer dot invalid> <5341A3F5 dot 2040506 at tiscali dot co dot uk> <CAHiT=DF117Jf0jdV8KQHOakkOw3_A5FvmSRKRRVnXGt-MLY6cA at mail dot gmail dot com> <8761mlx7im dot fsf at Rainer dot invalid> <CAHiT=DFhajOOFDeFseptmrPVXHGVjrAiFxDaW6Z7qQ6XR070DQ at mail dot gmail dot com> <87a9bvsnse dot fsf at Rainer dot invalid> <CAHiT=DEe1O4Vn7dp2mPwUNvEagZDtauu9_ZS1vfpEgZ+V0wt4A at mail dot gmail dot com> <8761loegk8 dot fsf_-_ at Rainer dot invalid> <87fvkq57do dot fsf at Rainer dot invalid> <87y4y8uoe2 dot fsf at Rainer dot invalid> <87k369lc8v dot fsf at Rainer dot invalid> <1408137347 dot 1564 dot 19 dot camel at YAAKOV04> <53EE830D dot 1010008 at tiscali dot co dot uk>
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 .
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
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
> 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.
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Terratec KOMPLEXER: