From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2696 invoked by alias); 7 Apr 2014 18:54:15 -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 2684 invoked by uid 89); 7 Apr 2014 18:54:14 -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-f176.google.com Received: from mail-ve0-f176.google.com (HELO mail-ve0-f176.google.com) (209.85.128.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 07 Apr 2014 18:54:12 +0000 Received: by mail-ve0-f176.google.com with SMTP id db11so3822010veb.7 for ; Mon, 07 Apr 2014 11:54:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.96.36 with SMTP id dp4mr4228764veb.21.1396896850573; Mon, 07 Apr 2014 11:54:10 -0700 (PDT) Received: by 10.220.159.197 with HTTP; Mon, 7 Apr 2014 11:54:10 -0700 (PDT) In-Reply-To: <5341A3F5.2040506@tiscali.co.uk> References: <534078A2.4000601@tiscali.co.uk> <87bnwf2cjl.fsf@Rainer.invalid> <534174C4.5010608@tiscali.co.uk> <87y4zi1kib.fsf@Rainer.invalid> <5341A3F5.2040506@tiscali.co.uk> Date: Mon, 07 Apr 2014 18:54: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/msg00015.txt.bz2 On Sun, Apr 6, 2014 at 1:59 PM, David Stacey wrote: > On 06/04/14 17:38, Achim Gratz wrote: >> >> David Stacey writes: >>> >>> Thank you for your reply. Yes, I was aware of that discussion. I'm not >>> talking about breaking up 'perl_vendor' for 32-bit Cygwin (although >>> IMHO that would be a good thing in the long term). I'd just like to >>> see the perl modules I mentioned adding to 64-bit Cygwin - and I'm >>> happy to maintain those packages myself if no-one else want to claim >>> ownership. >> >> I don't see why it should be a good idea to have different packaging for >> the two architectures, so I still think this issue needs to be decided. > > > Agreed. Hopefully the different collections of perl modules that are > available in the two architectures can be unified with the next perl > release. > > >> Anyway, here's what I have: > > > Yes, those are more or less identical to the packages that I prepared - I > could have done with those links a few days ago :-) It's rather nice (albeit > inefficient) to have two people trying to do the same thing - so often in > open source programmes no-one has the time! You've obviously put some > thought and effort into this, so I'm happy to step back and let you (or > Reini) to maintain these perl modules. The important thing is that they end > up in 64-bit Cygwin at some point. > > Thankfully, cygport makes most perl modules absurdly easy to maintain. So if > you need someone to adopt a few if and when 'perl_vendor' gets split up then > please let me know. > > Dave. The new 5.18.2 package will be unified for 32bit and 64bit, yes. perl_vendor will probably stay as is, as it is the easiest for the user and the maintainer. I still need to rebase all most-used XS modules esp. on 32bit perl to make sense and avoid dll base collisions on forks, which happens with CPAN, a basic bootstrap problem. My cygwin-specific rebase framework for CPAN modules still needs some love, esp. on 32bit. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/