Re: perl-5.18.2-1

[Achim Gratz <Stromeko@nexgo.de>]

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