Bug #53403 for B-Utils: B-Utils-0.10.tar.gz built with unsupported pax extensions

Tue Jan 05 11:10:54 2010 jpeacock [...] cpan.org - Ticket created

Subject:

B-Utils-0.10.tar.gz built with unsupported pax extensions

We have an internal app which builds across multiple architectures, so we have standardized on pax (instead of tar) for our archive extraction (better support under Solaris). Unfortunately, the B::Utils tarball has been built with a number of unsupported vendor headers, which pax is more than happy to extract (modern tar implementations will just ignore them). Sadly, that causes ExtUtils::MakeMaker to get confused and try and build the nested PaxHeader/Makefile.PL (see the attached file). And if the top-level PaxHeader directory is deleted, the resulting Makefile will try to run the t/PaxHeader/*.t test files.

It would be better for everyone if you just didn't include those headers at all. I'm sorry but I don't know what tool you used to generate the tarball, so I can't tell you what option to change.

Thanks

John

Subject:

first_attempt

Download first_attempt
application/octet-stream 1.6k

Message body not shown because it is not plain text.

Tue Jan 05 11:28:47 2010 jpeacock [...] cpan.org - Correspondence added

On Tue Jan 05 11:10:54 2010, JPEACOCK wrote:
Show quoted text

> I'm sorry but I don't know what tool you used to generate the
> tarball, so I can't tell you what option to change.

Looking around, it seems likely you are using star with the default options.  If you append "-O" (that is uppercase 'oh'), 
then it will not include the vendor extended headers.

Thanks

John

Tue Jan 05 11:28:48 2010 jpeacock [...] cpan.org - Status changed from 'new' to 'open'

Tue Jan 05 17:16:29 2010 JAWNSY [...] cpan.org - Correspondence added

Hi, While updating this package (libb-utils-perl) for Debian, we came across the exact same issue and are thus having problems updating it. From my brief (Google-based) research on the issue, it seems that this *may* be a bug in GNU tar, which should ignore these vendor extensions. Anyway, in the interest of getting it into Debian ASAP, I'd prefer that the tarball was repacked without these extensions. We have facilities to do this in Debian, but I'd really like to get it fixed upstream if possible. I'm glad that others have stepped forward to note that it affects them. Cheers, Jonathan

Mon Jan 11 22:24:56 2010 twists [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #53403] B-Utils-0.10.tar.gz built with unsupported pax extensions
Date:	Mon, 11 Jan 2010 19:24:38 -0800
To:	bug-B-Utils [...] rt.cpan.org
From:	Joshua ben Jore <twists [...] gmail.com>

On Tue, Jan 5, 2010 at 2:16 PM, Jonathan Yu via RT <bug-B-Utils@rt.cpan.org> wrote: Show quoted text

> Queue: B-Utils > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=53403 > > > Hi, > > While updating this package (libb-utils-perl) for Debian, we came across the exact same issue and are thus having problems updating it. From my brief (Google-based) research on the issue, it seems that this *may* be a bug in GNU tar, which should ignore these vendor extensions. > > Anyway, in the interest of getting it into Debian ASAP, I'd prefer that the tarball was repacked without these extensions. We have facilities to do this in Debian, but I'd really like to get it fixed upstream if possible. > > I'm glad that others have stepped forward to note that it affects them.

Just saw your note. Will upload J/JJ/JJORE/B-Utils-0.11.tar.gz tomorrow using the options you suggested. My build was: perl Makefile.PL make dist Whatever happened is whatever Ubuntu does by default. Josh

Wed Jan 13 16:08:48 2010 jjore [...] cpan.org - Correspondence added

On Tue Jan 05 11:10:54 2010, JPEACOCK wrote: Show quoted text

> We have an internal app which builds across multiple architectures, so > we have > standardized on pax (instead of tar) for our archive extraction > (better support > under Solaris). Unfortunately, the B::Utils tarball has been built > with a > number of unsupported vendor headers, which pax is more than happy to > extract > (modern tar implementations will just ignore them). Sadly, that causes > ExtUtils::MakeMaker to get confused and try and build the nested > PaxHeader/Makefile.PL (see the attached file). And if the top-level > PaxHeader > directory is deleted, the resulting Makefile will try to run the > t/PaxHeader/*.t test files. > > It would be better for everyone if you just didn't include those > headers at > all. I'm sorry but I don't know what tool you used to generate the > tarball, so > I can't tell you what option to change. > > Thanks > > John

Apparently Mac OS X is now using BSD tar by default which always adds the additional headers. GNU tar 1.19 or lower fails to extract the tarballs but this is a bug in GNU tar. BSD tar is apparently POSIXly correct in using novel headers. I'm talking to various toolchain folks about getting ExtUtils-MakeMaker to default to preferring GNU tar on BSD machines. If GNU tar isn't available then we should try using ustar format. If the user ID is greater than 0777777 octal then the package comes out completely busted. There may be a place for the CPAN module Archive::Tar in here somewhere. FWIW, I manually created B-Utils-0.11.tar.gz with GNU tar and uploaded it yesterday.

Mon Jan 24 04:11:16 2011 jjore [...] cpan.org - Correspondence added

Resolved with 0.11

Mon Jan 24 04:11:17 2011 jjore [...] cpan.org - Status changed from 'open' to 'resolved'