Front page | perl.perl5.porters |
Postings from October 2009
> From: Steve Hay [mailto:steve.m.hay@googlemail.com]
> 2009/10/4 Paul Marquess <Paul.Marquess@ntlworld.com>:
> > From: Steve Hay [mailto:steve.m.hay@googlemail.com]
> >
> >> 2009/10/4 Paul Marquess <Paul.Marquess@ntlworld.com>:
> >> >> From: Steve Hay [mailto:steve.m.hay@googlemail.com]
> >> > ...
> >> >>
> >> >> I think what you're suggesting wouldn't work precisely because of
> >> the
> >> >> core changes:
> >> >>
> >> >> http://perl5.git.perl.org/perl.git/commit/4cc80fc (for *nix)
> >> >> http://perl5.git.perl.org/perl.git/commit/f4a6a71 (for Win32)
> >> >>
> >> >> Those change ensure that the new non-XS versions of these modules
> >> >> available in 5.10.1 get installed into the architecture-dependent
> >> lib
> >> >> folder just like the old XS versions!
> >> >
> >> > But why does it need to be installed in an architecture-dependent
> >> folder at
> >> > all? IO-Compress doesn't (or shouldn't) contain anything
> >> > architecture-dependent -- all the that logic lives in the
> Compress-
> >> Raw-*
> >> > modules.
> >>
> >> It's because of your previous explanation about Compress-Zlib having
> >> previously been an XS module. We need to continue pretending that it
> >> still is to avoid upgrade trouble, given that archlib is in @INC
> >> before lib.
> >
> > For legacy versions of perl, I agree, I'm stuck with messing with
> INST_LIB.
> > For future releases of Perl do we not have the opportunity to make
> the
> > problem go away by getting core to assume it not architecture-
> dependent and
> > have the latest CPAN version out in the wild know what it should do
> for Perl
> > versions >= 5.10.2?
> >
> > So the logic in Makefile.PL becomes something like this (completely
> > untested)
> >
> > (
> > $] >= 5.009 && $] <= 5.010001 && ! $ENV{PERL_CORE}
> > ? (INSTALLPRIVLIB => '$(INSTALLARCHLIB)')
> > : ()
> > )
>
> But what about people who have, say, 5.10.1 installed, and then
> upgrade to 5.10.2 in the same installation directory? They should be
> backwards-compatible, so that should work without having to start over
> with a fresh perl installation, but if we switch to the logic above
> and revert the corresponding core change to installperl and
> win32/FindExt.pm to match then the 5.10.2 files will go into lib and
> won't be seen because of existing 5.10.1 files already in archlib.
Do people actually do that? Any time I ever upgrade, I start from scratch
and wipe the old one.
> I think you're right that it doesn't need to stay in archlib
> long-term, but I think it has to stay where it is for 5.10.x.
I'm happy to go along with that if in-place upgrades are likely to be a
problem.
> What
> happens with 5.11.x probably doesn't matter so much given that they're
> development versions anyway, so maybe make the above $] >= 5.009 && $]
> <= 5.011001 ? Then revert the two core changes to match, and make sure
> that the original two core changes get merged into 5.10.x (the
> installperl change is in already, but the win32/FindExt.pm change
> isn't yet), and especially make sure that the change that reverts them
> doesn't get merged into 5.10.x.
Ok.
Paul
Thread Previous
|
Thread Next