[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