[MacPorts] #61276: meson @0.55.3: /usr/bin/gnutar: meson-0.55.3/COPYING: implausibly old time stamp 1970-01-01 01:00:00

[MacPorts]

#61276: meson @0.55.3: /usr/bin/gnutar: meson-0.55.3/COPYING: implausibly old time
stamp 1970-01-01 01:00:00
------------------------+---------------------------------------------
  Reporter:  ballapete  |      Owner:  git@…
      Type:  defect     |     Status:  assigned
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.6.3
Resolution:             |   Keywords:  tiger leopard powerpc legacy-os
      Port:  meson      |
------------------------+---------------------------------------------
Changes (by ryandesign):

 * cc: bryancn (added)
 * keywords:  tiger powerpc legacy-os => tiger leopard powerpc legacy-os


Comment:

 Has duplicate #61819.

 Replying to [comment:10 ballapete]:
 > Replying to [comment:9 kencu]:
 > > So -- I guess we're making gnutar a dependency for -- what? -- using
 xz on older systems?
 >
 > Actually `gnutar` does not need to have any dependency. If it finds any
 of `xz | bzip2 | gzip | lzip | lzma | lzop | compress` it can handle
 compressed tape archives.

 Ken was suggesting that we should modify MacPorts base so that, when the
 distfile is an xz-compressed tarball, we use MacPorts gnutar instead of
 Tiger or Leopard's older version. However, duplicate #61819 shows that the
 problem is not specific to xz compression; in that ticket, it was a gz-
 compressed tarball. So the problem is presumably that some modern tar
 archives, regardless of what type of compression is later applied to them,
 cannot be extracted by the version of gnutar on Tiger or Leopard. Whether
 this is a bug in some modern tar archive creator, or whether these tar
 archives are valid and there is a bug in the decompression routines in
 Tiger and Leopard's gnutar, is unknown. It may be worthwhile for someone
 to investigate. If it turns out that these archives are invalid, then that
 bug could be fixed in whatever tool was used to create the archives, and
 then over time fewer invalid archives would be created as people upgrade
 their tools.

 MacPorts handles decompression separately from untarring, so it is
 unlikely that the compression type has any bearing on our ability to
 process the uncompressed tarball inside.

 Probably the only solution we have for this at the moment is that
 individual ports that use distfiles that have this quality should have
 code added to them to use port gnutar on those older systems. I don't know
 of a way that MacPorts base could detect this problem and do so
 automatically, since the port's dependencies must be determinable before
 the distfile has been downloaded.

 > `xz` should become a part of `MacPorts`

 The request to do so is #52000 but there is no consensus that we should do
 so.

 > how does it work on Catalina or such with `xz` compressed archives?
 Apple does not put `xz` in macOS…

 When a portfile specifies `use_xz yes`, MacPorts base automatically adds
 an extract dependency on `port:xz`.

 OS X 10.9 and later can decompress xz files, even though they do not
 include the xz binary. The request to use this facility in MacPorts base
 and thus avoid the dependency on `port:xz` is #56237 but nothing has been
 done about it yet.

 > A clever option would be if `port` would be able to determine which of
 the compressors exists on the system and then decide to fetch the most
 efficient file – which would mean to take into account data rate of the
 internet connection, speed of the file system and RAM, and power of the
 CPU.

 I see no reason to do anything of this kind. This would involve many
 complicated changes to MacPorts base, and I don't see what the benefit
 would be.

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