[MacPorts] #70622: automake @1.17_0 fails to install on 10.4

[MacPorts]

#70622: automake @1.17_0 fails to install on 10.4
------------------------+--------------------
  Reporter:  fhgwright  |      Owner:  (none)
      Type:  defect     |     Status:  new
  Priority:  Normal     |  Milestone:
 Component:  base       |    Version:  2.10.1
Resolution:             |   Keywords:
      Port:             |
------------------------+--------------------

Comment (by berg-michael):

 I am not able to prove this definitively as I don't have a recent macOS
 machine to test.

 However, I think this might be caused by recent versions of bsdtar which
 default to the pax archive format. I see rumblings about these changes
 (https://www.undeadly.org/cgi?action=article;sid=20240417053301,
 https://bugs.python.org/issue36268) in other environments and suspect it
 happened on macOS as well.

 Nominally, gnutar 1.14 should be able to handle this. Actually, it does
 successfully extract the archive with no errors. It only produces an error
 when asked for a specific file in such an archive, and it's still able to
 extract the requested file first. It seems like there is just some bug in
 this old version of gnutar.

 My evidence:

 py310-setuptools 72.2.0 used to be broken in the same way on 10.4. 74.1.2
 works fine.

 If one runs
 {{{
 bzip2 -cd py310-setuptools-72.2.0_0.darwin_any.noarch.tbz2  | less -
 }}}

 or

 {{{
 bzip2 -cd automake-1.17_0.any_any.noarch.tbz2  | less -
 }}}

 one will find ./PaxHeader in the output. However, running


 {{{
 bzip2 -cd py310-setuptools-74.1.2_0.darwin_any.noarch.tbz2  | less -
 }}}

 i.e. the same test on a known working file, there is no ./PaxHeader.

 (there's probably a more robust way to determine the format, but this was
 good enough for me).

 I suspect there will not be a great way to work around this at extract
 time. gnutar is able to extract the file successfully, as I mentioned, but
 not if a specific file is requested.

 Probably, the best solution is to ensure that tarballs are generated in
 the GNU format going forward. I believe this was the prior default, though
 I am open to being corrected. Virtually everything I know about tarballs
 was learned in the last few hours or so.

 It should be possible to do a sweep of the existing tarballs and re-
 tarball them in the older format. This would not require rebuilding, just
 repackaging. The scope of the sweep probably could be narrowed by not
 considering files with a creation date before the default was changed to
 Pax, if such a date can be determined.

-- 
Ticket URL: <https://trac.macports.org/ticket/70622#comment:4>
MacPorts <https://www.macports.org/>
Ports system for macOS