From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14470 invoked by alias); 8 Apr 2014 20:52:40 -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 14444 invoked by uid 89); 8 Apr 2014 20:52:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_40,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ve0-f175.google.com Received: from mail-ve0-f175.google.com (HELO mail-ve0-f175.google.com) (209.85.128.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 08 Apr 2014 20:52:38 +0000 Received: by mail-ve0-f175.google.com with SMTP id oz11so1281812veb.6 for ; Tue, 08 Apr 2014 13:52:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.220.133.80 with SMTP id e16mr5018837vct.13.1396990355843; Tue, 08 Apr 2014 13:52:35 -0700 (PDT) Received: by 10.220.159.197 with HTTP; Tue, 8 Apr 2014 13:52:35 -0700 (PDT) In-Reply-To: <87a9bvsnse.fsf@Rainer.invalid> 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> Date: Tue, 08 Apr 2014 20:52:00 -0000 Message-ID: Subject: Re: 64-bit: Missing perl modules From: Reini Urban To: cygwin-apps Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00030.txt.bz2 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.