[MacPorts] #67336: tar on Ventura is broken, what shall we do?

MacPorts noreply at macports.org
Mon May 1 10:49:24 UTC 2023


#67336: tar on Ventura is broken, what shall we do?
---------------------+--------------------
  Reporter:  catap   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  High    |  Milestone:
 Component:  base    |    Version:
Resolution:          |   Keywords:
      Port:          |
---------------------+--------------------

Comment (by catap):

 Replying to [comment:9 ryandesign]:
 > Replying to [comment:2 catap]:
 > > Replying to [comment:1 ryandesign]:
 > > > Surely this is not a general bug in tar on Ventura, else it would
 have been reported by now.
 > >
 > > Unfortunately I'd like to disagree with you. After knowing that it is
 tar on macOS, I've discovered that it is well known issue.
 > >
 > > For example: https://github.com/actions/runner-images/issues/2619
 >
 > What I meant is: we have built tens of thousands of ports on the Ventura
 buildbot workers and this problem either hasn't occurred there or hasn't
 caused issues. For example, if it were the case that extracting any port's
 archive, or specific ports' archives, always failed, then we would expect
 some ports to fail to install on the buildbot because of it, but we either
 haven't seen that happen, or we haven't realized that some failures may be
 attributable to this issue. In any case the problem doesn't seem to affect
 all users all of the time. It is not a 100% reproducible bug.

 I accidentally found this problem in the pari port, and ecgeb, which
 depends on pari, has no artifact for Ventura x86 either:
 https://ports.macports.org/port/ecgen/details/ :)

 My guess is that it happens, but nobody really cares enough to report it.
 New users facing this problem have probably given up on MacPorts.

 > Thanks for the link. I've read it and some other related links and it
 does sound like an OS bug and that lack of reproducibility is commonly
 reported. Seems that Homebrew has applied the workaround that optionally
 calls `purge` around the code that creates the archives:
 >
 >
 https://github.com/Homebrew/brew/commit/36dac3d41feafa09f82dedb63e51fabf5f0ea358
 >
 > Maybe we should do the same in MacPorts base.

 I am not sure if it is possible to do this within MacPorts, because this
 call requires `sudo` and MacPorts can be used without it.

 Honestly, I haven't seen a good solution for this: switching to gnutar
 means forcing users to install it, and if we decide to go that way, let's
 switch to xar or xz, which will save disk space and traffic :)

 Anyway, as a workaround, switching some rare ports to xar seems to be the
 best possible option, to be honest.

 > I may have encountered a form of this issue myself with the mongodb
 port. I hadn't reported it because it wasn't consistently reproducible and
 I could not figure out whether it was a bug in the mongodb build system or
 something else, and it takes so long to build that it is difficult to
 debug. But on one of my Macs with Catalina, and on another Mac with
 Monterey, I have occasionally encountered sections of the `mongod` binary
 being replaced with zeroes, making the file unusable.

 Shall that port also be switched to xar?

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


More information about the macports-tickets mailing list