Skip Menu |

This queue is for tickets about the P CPAN distribution.

Report information
The Basics
Id: 90165
Status: resolved
Priority: 0/
Queue: P

People
Owner: pause [...] tlinx.org
Requestors: SREZIC [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Subject: Tarball extraction problems using older Archive::Tar (pax extended headers)
With P-1.1.3.tar.gz and P-1.1.4.tar.gz there are extraction problems with older Archive::Tar. I observed this on an old Debian squeeze system while building P using CPAN.pm, which is configured to use Archive::Tar for extraction (the default setting then). "ptar -t -z -f P-1.1.4.tar.gz" shows the following output: ./PaxHeaders.72794/P-1.1.4 P-1.1.4/ P-1.1.4/PaxHeaders.72794/MANIFEST P-1.1.4/MANIFEST P-1.1.4/PaxHeaders.72794/lib P-1.1.4/lib/ P-1.1.4/lib/PaxHeaders.72794/P.pm P-1.1.4/lib/P.pm P-1.1.4/PaxHeaders.72794/t P-1.1.4/t/ P-1.1.4/t/PaxHeaders.72794/P.t P-1.1.4/t/P.t P-1.1.4/PaxHeaders.72794/Changes P-1.1.4/Changes P-1.1.4/PaxHeaders.72794/Makefile.PL P-1.1.4/Makefile.PL P-1.1.4/PaxHeaders.72794/LICENSE P-1.1.4/LICENSE P-1.1.4/PaxHeaders.72794/README P-1.1.4/README P-1.1.4/PaxHeaders.72794/META.yml P-1.1.4/META.yml P-1.1.4/PaxHeaders.72794/META.json P-1.1.4/META.json So during extraction extra "PaxHeaders" directories are created. The multiple toplevel directories are confusing CPAN.pm, and the build eventually fails. This is an Archive::Tar problem, and it's described in https://rt.cpan.org/Ticket/Display.html?id=64038 and solved in Archive::Tar 1.74. But it would be good if you could find a way to build the distribution with a different tool or different options or maybe on an other OS. Regards, Slaven
Interesting. Didn't know gnu-tar produced those headers, but they are following a 12-year old POSIX 1003.1-2001 spec where they decided on pax format over ustar format that was from 1003.1-1988. How old is the build system ?? 2001 was back in about the linux 2.2 days? (FWIW building on an openSuSE version of linux)... the gnu tar has switches for .. well let me copy them in: -H, --format=FORMAT create archive of the given format FORMAT is one of the following: gnu GNU tar 1.13.x format oldgnu GNU format as per tar <= 1.12 pax POSIX 1003.1-2001 (pax) format posix same as pax ustar POSIX 1003.1-1988 (ustar) format v7 old V7 tar format --- But I don't know if there are any problems with using older formats. The one that it defaults to seems to be pax. This is news to me -- tried unpacking it with bsdtar, and that didn't have the problem, had to hexdump it to see the headers. If it is a 12 year old posix standard, what system would I build on that wouldn't likely use that? I'll look into seeing how to config make maker to pass in the the format=v7, and that should make things happy (I hope, but won't know until I try it...).
On 2013-11-09 01:58:36, LAWALSH wrote: Show quoted text
> Interesting. Didn't know gnu-tar produced those headers, but they are > following a 12-year old POSIX 1003.1-2001 spec where they decided on > pax format over ustar format that was from 1003.1-1988. > > How old is the build system ?? > > 2001 was back in about the linux 2.2 days? > > (FWIW building on an openSuSE version of linux)... > > the gnu tar has switches for .. well let me copy them in: > > -H, --format=FORMAT > create archive of the given format > > FORMAT is one of the following: > > gnu GNU tar 1.13.x format > > oldgnu GNU format as per tar <= 1.12 > > pax POSIX 1003.1-2001 (pax) format > > posix same as pax > > ustar POSIX 1003.1-1988 (ustar) format > > v7 old V7 tar format > > --- > But I don't know if there are any problems with using older formats. > > The one that it defaults to seems to be pax. > > This is news to me -- tried unpacking it with bsdtar, and that didn't > have the problem, had to hexdump it to see the headers. > > If it is a 12 year old posix standard, what system would I build on > that wouldn't likely use that? > > I'll look into seeing how to config make maker to pass in the the > format=v7, and that should make things happy (I hope, but won't know > until I try it...).
I found the following on https://www.suse.com/releasenotes/x86_64/openSUSE/12.2/#technical : " 5.10. GNU tar Defaults to Creating POSIX-compliant Archives GNU tar now defaults to --format=posix and create POSIX-compliant archives with PAX extended headers. Check whether your scripts and applications are compatible with this format. The former behavior (and upstream default) can be restored by setting the environment: TAR_OPTIONS='--format=gnu' or TAR_OPTIONS='--pax-option=delete=[ac]time*' " So maybe you can try one of the two options when building the distributions. I don't know if the --pax-option=delete is enough here, as I also see a "mtime" header, so maybe this should be [acm]time* If you want to try yourself, then just try it out with an old Archive::Tar like this: cpan Show quoted text
cpan> look KANE/Archive-Tar-1.52.tar.gz
perl Makefile.PL && make env PERL5LIB=blib/lib blib/script/ptar -t -z -f /usr/local/src/CPAN/sources/authors/id/L/LA/LAWALSH/P-1.1.4.tar.gz The listing should not contain any visible PaxHeaders directories. If everything works, then maybe we have to think about getting some changes in ExtUtils::MakeMaker and Module::Build... Regards, Slaven
Fixed in 1.1.5. I used tar c --format=v7 -f P-1.1.5.tar P-1.1.5 Seems to be fine...;-)
On 2013-11-10 21:46:35, LAWALSH wrote: Show quoted text
> Fixed in 1.1.5. > > I used > tar c --format=v7 -f P-1.1.5.tar P-1.1.5 > > Seems to be fine...;-) >
The new tarball works on my Debian/squeeze VM. But mem-0.3.2.tar.gz also has this issue... Regards, Slaven
Subject: Re: [rt.cpan.org #90165] Tarball extraction problems using older Archive::Tar (pax extended headers)
Date: Mon, 11 Nov 2013 14:38:09 -0800
To: bug-P [...] rt.cpan.org
From: "Linda A. Walsh" <lawalsh [...] cpan.org>
On 11/11/2013 1:40 PM, Slaven_Rezic via RT wrote: Show quoted text
> The new tarball works on my Debian/squeeze VM. But mem-0.3.2.tar.gz > also has this issue... > Regards, > Slaven >
What I'm not sure is where I can put that so that it is done globally for all packages built. What concerns me is if anyone else tries to build it and is using a different tar... then it will likely die.. No? I mean that seems problematic...(Ug)...