You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ExtUtils::MakeMaker uses by default system /bin/tar binary for creating distribution archives when invoking make dist. On more systems /bin/tar binary by default creates PAX archives instead of classic TAR archives. When you try to unpack PAX archive by a program which understands only ustar (and not pax), it creates PaxHeader subdirectory and in this subdirectory creates random files and their content has raw PAX extended attributes. So it is common that such tar program creates PaxHeader/Makefile.PL with some random garbage. It is not valid Perl code and existing it fails. So on such systems it is not possible to install perl distributions from PAX archives. There are more bug reports about this issue, e.g.: Dual-Life/Devel-PPPort#183 https://huntingbears.nl/2015/02/17/new-tar-paxheaders-and-installing-from-cpan/ http://www.perlmonks.org/?node_id=1004571
So correct way to generate a new distribution is to use ustar archive and not PAX archive.
Perl since 5.10 has in Core module Archive::Tar and ptar binary which creates TAR archives, not PAX. So ExtUtils::MakeMaker could switch from /bin/tar to ptar by default to fix this problem and prevent creating of PAX archives on systems which /bin/tar binary by default creates PAX and not ustar. IIRC new versions of GNU tar already switched default to PAX, so Perl core ptar looks like a solution for this problem.
There is already proposed change to use --format=ustar flag for /bin/tar, but in discussion was a point that this option works correctly only for GNU tar implementation. For BSD tar implementation it in some cases creates empty tar archives... See discussion: xsawyerx/module-starter#73
The text was updated successfully, but these errors were encountered:
ptar does look like a solution here. However, a change to use it by default may break the Makefile.PL of users who tried to work around this issue by adding --format=ustar to their TARFLAGS.
Perhaps Archive::Tar’s ptar should be changed so that it accepts (and ignores) an argument --format=ustar?
Or ExtUtils::MakeMaker could remove --format=ustar from TARFLAGS when TAR isn’t defined (and defaults to ptar)?
ExtUtils::MakeMaker uses by default system /bin/tar binary for creating distribution archives when invoking
make dist
. On more systems /bin/tar binary by default creates PAX archives instead of classic TAR archives. When you try to unpack PAX archive by a program which understands only ustar (and not pax), it creates PaxHeader subdirectory and in this subdirectory creates random files and their content has raw PAX extended attributes. So it is common that such tar program creates PaxHeader/Makefile.PL with some random garbage. It is not valid Perl code and existing it fails. So on such systems it is not possible to install perl distributions from PAX archives. There are more bug reports about this issue, e.g.:Dual-Life/Devel-PPPort#183
https://huntingbears.nl/2015/02/17/new-tar-paxheaders-and-installing-from-cpan/
http://www.perlmonks.org/?node_id=1004571
So correct way to generate a new distribution is to use ustar archive and not PAX archive.
Perl since 5.10 has in Core module Archive::Tar and
ptar
binary which creates TAR archives, not PAX. So ExtUtils::MakeMaker could switch from /bin/tar to ptar by default to fix this problem and prevent creating of PAX archives on systems which /bin/tar binary by default creates PAX and not ustar. IIRC new versions of GNU tar already switched default to PAX, so Perl coreptar
looks like a solution for this problem.There is already proposed change to use
--format=ustar
flag for /bin/tar, but in discussion was a point that this option works correctly only for GNU tar implementation. For BSD tar implementation it in some cases creates empty tar archives... See discussion: xsawyerx/module-starter#73The text was updated successfully, but these errors were encountered: