Re: Module::Build 0.30 is released - ppm.t on VMS depends on Archive::Tar patch.
Hi John, On Oct 1, 2008, at 2:51 AM, John E. Malmberg wrote: Steve Hay wrote: Ken Williams wrote: Hi all, After much tireless work by Eric Wilhelm and lots of feedback from patient nonpatient users alike, I'm pleased to announce that version 0.30 of Module::Build is now on CPAN. This is the first non-beta release in a long time. Thanks, applied to bleadperl as 34446. Two local changes remain: Change 32357 by [EMAIL PROTECTED] on 2007/11/17 04:19:47 Skip Module::Build ppm test -- not ready for prime time on VMS. http://www.nntp.perl.org/group/perl.vmsperl/2008/06/msg14821.html The main problem is that Archive::Tar needs a patch to properly be able to pack a VMS binary into a tarball. We were waiting for word from Jos on this. It was my understanding that this was already applied to core, and it's also part of Archive::Tar 1.39_01: http://search.cpan.org/src/KANE/Archive-Tar-1.39_04/CHANGES A::T 1.39_04 looks stable, so we can promote it to 1.40 shortly. Is there anything specific you need me to do now? Cheers, -- Jos Boumans 'Real programmers use cat a.out'
Re: Module::Build 0.30 is released - ppm.t on VMS depends on Archive::Tar patch.
Jos I. Boumans wrote: Hi John, On Oct 1, 2008, at 2:51 AM, John E. Malmberg wrote: http://www.nntp.perl.org/group/perl.vmsperl/2008/06/msg14821.html The main problem is that Archive::Tar needs a patch to properly be able to pack a VMS binary into a tarball. We were waiting for word from Jos on this. It was my understanding that this was already applied to core, and it's also part of Archive::Tar 1.39_01: I just verified that the fix is not in blead perl as of today's rsync copy just now. To be more specific it is a patch to Archive/Tar/File.pm to fix handling of VMS binary executable files. It also fixes setting the UID properly when saving the UID is requested. http://search.cpan.org/src/KANE/Archive-Tar-1.39_04/CHANGES Yes I see that the patch is in the changelog. A::T 1.39_04 looks stable, so we can promote it to 1.40 shortly. Is there anything specific you need me to do now? It looks like we need for blead to get more up to date. I also need to find the time to get the fix into gnu tar, because it is also mis-handling the VMS file sizes for executable binaries. Gnu tar also needs a fix for handling VMS GID values on creating an archive, which I also noticed when debugging this issue. As it is right now, A::T 1.39_04 is probably the only way to build a tarball on VMS that includes an executable binary. -John [EMAIL PROTECTED] Personal Opinion Only
RE: Module::Build 0.30 is released - ppm.t on VMS depends on Archive::Tar patch.
John E. Malmberg wrote: Jos I. Boumans wrote: Hi John, On Oct 1, 2008, at 2:51 AM, John E. Malmberg wrote: http://www.nntp.perl.org/group/perl.vmsperl/2008/06/msg14821.html The main problem is that Archive::Tar needs a patch to properly be able to pack a VMS binary into a tarball. We were waiting for word from Jos on this. It was my understanding that this was already applied to core, and it's also part of Archive::Tar 1.39_01: I just verified that the fix is not in blead perl as of today's rsync copy just now. To be more specific it is a patch to Archive/Tar/File.pm to fix handling of VMS binary executable files. It also fixes setting the UID properly when saving the UID is requested. http://search.cpan.org/src/KANE/Archive-Tar-1.39_04/CHANGES Yes I see that the patch is in the changelog. A::T 1.39_04 looks stable, so we can promote it to 1.40 shortly. Is there anything specific you need me to do now? It looks like we need for blead to get more up to date. Blead is now updated to Archive-Tar-1.39_04 in #34452. One local change remains in blead: Change 32352 by [EMAIL PROTECTED] on 2007/11/16 23:46:13 The new Archive::Tar tests are TODO on VMS for reasons unrelated to the security issue for which they are testing. and I've just made another local change to fix a test that was failing after the upgrade: Change 34453 by [EMAIL PROTECTED] on 2008/10/01 16:55:42 Fix Archive-Tar's 02_methods.t when IO::Compress::Bzip2 is absent (We haven't got IO::Compress::Bzip2 in blead, and can_handle_compressed_files() checks for both IO::Zlib and IO::Compress::Bzip2, which caused test 1 to fail without this change. Hmm... Thinking some more (sadly *after* I just hit submit, perhaps it would have been better to change test 1 to check against $ZLIB $BZIP, rather than changing the meaning of $ZLIB?)
Re: Module::Install is a time bomb
# from Ricardo SIGNES
# on Wednesday 01 October 2008:
* Ken Williams [EMAIL PROTECTED] [2008-10-01T12:15:04]
On Wed, Oct 1, 2008 at 11:12 AM, Smylers [EMAIL PROTECTED] wrote:
But what if the bundled version of latest.pm is buggy and I
already have a later latest.pm installed on my system? That will
use the wrong one!!
latest.pm doesn't ever get installed on anyone's computer. If you
install it, we have a backup plan for that too - the guys in black
coats will come and take your computer away.
Well, at this point we're back to everybody must upgrade everything.
Presumably latest.pm knows to use the installed latest.pm if it's
later, even if this is rarely true and even more rarely needed.
There is no 'installed latest.pm', and yes this is a potential for bugs
with any bundling solution. Even if there were an 'installed
latest.pm', what if the bundled latest.pm had a bug where it failed to
give way to the installed one?
We could recommend that the Build.PL does BEGIN {push(@INC, 'inc')}
instead of use lib 'inc' (an unshift()), which gives the target the
opportunity to upgrade (or break) their latest.pm.
But what we're talking about is allowing the target machine to escape
from a bad situation caused by hard-coded/bundled code -- and that can
be solved with a simple unshift(@INC, sub {...}) or various other
hackery where you would say perl -MDevel::noinc Build.PL or whatever.
But latest.pm is fairly short and simple, which reduces the bug rate.
It could probably still use some testing -- given that I just fixed a
non-starter bug in it the other day, I appear to be the only user.
--Eric
--
Beware of bugs in the above code; I have only proved it correct, not
tried it.
--Donald Knuth
---
http://scratchcomputing.com
---
