Re: 64-bit: Missing perl modules

[Achim Gratz <Stromeko at nexgo dot de>]

Reini Urban writes:
> Already did. It's vastly easier to keep perl_vendor than to split it up.
> For all parties.

Then consider me not a party.  For me keeping perl_vendor an opaque
bundle is making things more difficult.  I could special-case it into
all the dependecy tests, but seeing that unbundling it is actually
easier, I don't see why I should.  This unbundling lets me update
individual distributions from perl_vendor independently, which has been
quite useful.

>>> You can do individual perlrebase or wait for the full autorebase for
>>> every XS installation.
>>
>> Or do an ephemeral rebase that is taking the rebase map of the rest of
>> the system correctly into account.
>
> Only if you register each and every user module with the system.
> But we don't want that.

Wait, weren't we talking about vendor-perl, possibly site-perl?  These
two locations are already "registered with the system".  The only
head-scratcher for me are always inline modules compiled on the fly and
stuffed into private directories.  Rebase doesn't provide for any
private libraries and really it can't since this is a system-wide issue.

> I know that you want to cygport every single perl module, but this is a very
> extreme position.

Again, as long as CPAN or cpanm or whatever honors @INC, the next
incremental rebase keeps things in order.  The same for ruby and
octave.  I've explained why I package all distributions and why opaque
bundles are unhelpful, but this has nothing whatsoever to do with the
need for rebasing.

> True. With proper EUMM and MB integration we would need no perlrebase.
> But MB is a mess. And Module::Install even more. And I wonder what will
> come up next. MB::Lite is already in the works just to bypass GNU make.

We'll see how this works.  Today I've dealt with that bright idea to
"protect" the UNTAINT test in Inline.  That really doesn't work that way
in Cygwin and I'm still not sure what it is supposed to protect me from
(ending up with an empty path).

> Fair enough. But then I would keep them uptodate with a simple cpan or
> rsync, which is better than setup.exe.

No can do, even if it was better.

> No need to stop all services.

Really, there's a lot more stuff our IT does that stops services than a
Cygwin update.

> cpan ensures proper testing and with CPAN::Reporter being integrated
> the authors even get feedback.

Again, not something that I can do and not the point of our discussion,
which was the opaque bundling within perl_vendor.


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