From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8986 invoked by alias); 12 Jul 2012 15:24:24 -0000 Received: (qmail 8967 invoked by uid 22791); 12 Jul 2012 15:24:22 -0000 X-SWARE-Spam-Status: No, hits=-5.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com) (209.85.217.171) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 Jul 2012 15:24:08 +0000 Received: by lbom4 with SMTP id m4so3371938lbo.2 for ; Thu, 12 Jul 2012 08:24:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.49.227 with SMTP id x3mr1322820lbn.73.1342106646479; Thu, 12 Jul 2012 08:24:06 -0700 (PDT) Received: by 10.112.86.130 with HTTP; Thu, 12 Jul 2012 08:24:06 -0700 (PDT) In-Reply-To: <87pq81d09k.fsf@Rainer.invalid> References: <87mx36z0yo.fsf@Rainer.invalid> <7FA8477365204CA6B4617E7279967C24@multiplay.co.uk> <87a9z6ywvp.fsf@Rainer.invalid> <60B4845A414A4F228982AB4DEAF4D4FE@multiplay.co.uk> <87pq81d09k.fsf@Rainer.invalid> Date: Thu, 12 Jul 2012 15:24:00 -0000 Message-ID: Subject: Re: perl-5.14.2 switch From: Reini Urban To: cygwin@cygwin.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-07/txt/msg00222.txt.bz2 On Thu, Jul 12, 2012 at 12:19 AM, Achim Gratz wrote: > Steven Hartland writes: >> Unfortunately the current perl_vendor install is so broken cpan >> won't allow you to fix it with simple "install" unless you know >> the exact missing modules and just breaks in some very strange >> and random ways. Like missing protocol for ftp in LWP You are right. Back when I managed the _vendor list LWP was still pre-6.0 and had different deps. I needed LWP to get CPAN and then CPAN::TestReporter to work (at least bootstrap), so people can manage their own packages, and do not rely on cygwin packages. And the upstream maintainers get windows reports about failures, which they need to fix their stuff. They always complain not getting any windows reports, so they rather bitch. At least they get cygwin reports for some time now. I've updated the list of missing deps yesterday. > I suggested to use cpanminus =97 not cpan =97 for a reason. It is possib= le > to get things to eventually work as you want via CPAN, but it is much > less effort to do so via cpanminus. You can then continue using CPAN > for new modules if you wish. Agreed. > Remove perl_vendor first, in the end this is much easier than papering ov= er it > via site-perl. Sorry for the missing deps conflicts. This will be fixed in 5.14.2-3. > Also, make sure you have removed all remnants from perl-5.10 (including > locally installed modules). The ability of 5.14 to fall back to modules > that were installed for 5.10 is a double-edged sword, the two versions > are sufficiently different so that I would not want to mix them at the > module level. I do not agree. XS modules are not looked up from 5.10, and there is no problem to continue using old modules if they were never updated on CPAN. If so, you well get new ones anyway with your next cpan or cpanm update. It's a one-liner, but needs a lot of time to re-install everything from scr= atch. $ cat ~/bin/cpanautoinstall #!/usr/bin/env perl use CPAN; CPAN::Shell->install(CPAN::Shell->r) or just: $ perl -MCPAN -e'CPAN::Shell->install(CPAN::Shell->r)' One other remaining problem is libtool's inability to mix static Win32CORE.a with shared, so I'll probably add Win32CORE.o to libperl instead. It's a sh= ame. But perl is also blame as it still does not support installing static_ext .a libs. I have to do that manually. > Last but not least, Reini has asked for testers of the new perl quite a > while back and didn't get all that many responses. Even with those > kinks in perl_vendor (which I'm sure he'll fix) the 5.14 to me is the > least problematic perl version on Cygwin so far. I have only a glimpse > of how much work that must have been and I really appreciate it. I'm > sure Reini wouldn't mind if someone just took the sources for > perl_vendor and fixed whatever needs fixing and feed back the changes to > him... Well, I'm not so happy with threads. They seem to be more broken than with = 5.10. But I like 5.14.2 generally at most of all also, much better than the completely flawed 5.16. --=20 Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple