This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: 64-bit: Missing perl modules
- From: Reini Urban <rurban at x-ray dot at>
- To: cygwin-apps <cygwin-apps at cygwin dot com>
- Date: Tue, 8 Apr 2014 15:52:35 -0500
- Subject: Re: 64-bit: Missing perl modules
- 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>
On Tue, Apr 8, 2014 at 1:01 PM, Achim Gratz wrote:
> Reini Urban writes:
>> Nope.
>
> Care to explain?
Already did. It's vastly easier to keep perl_vendor than to split it up.
For all parties.
>> 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.
I know that you want to cygport every single perl module, but this is a very
extreme position.
>> With individual split perl_vendor packages the user needs to wait for
>> every single rebase update.
>
> No. You can run the incremental rebase directly if you wish and as long
> as the rest of the system had been rebased correctly it will only touch
> the new stuff.
>
>> With the combined perl_vendor I'll do it as part of the build step and
>> the user only needs to wait for one rebase run.
>
> You wouldn't need a special perlrebase for that, that's the whole point.
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.
>> Sure, that's automatic of you care to package everything.
>> But updates come every week, not every two years.
>
> In my case I have to package things anyway since I need to distribute
> the to a bunch of machines that have no outward connection. Besides the
> need for an internal CPAN mirror, I'd generally not trust a random user
> to run a CPAN update and make a judgment of whether or not everything
> worked as expected. Packaging some 300 Perl distributions really is
> less work than any of the alternatives and keeping things up-to-date
> isn't all that time-consuming so far.
Fair enough. But then I would keep them uptodate with a simple cpan or
rsync, which is better than setup.exe.
No need to stop all services.
I maintain about 40 VM's this way, cross-version and platform.
cpan ensures proper testing and with CPAN::Reporter being integrated
the authors even get feedback.
strawberry perl does the same.