This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: perl-5.14.2 switch
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 — not cpan — for a reason. It is possible
> 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 over 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 scratch.
$ 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 shame.
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.
--
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