Well… It is quite common that every next update breaks a port, because nothing is tested with gcc, not on a single system. And then CI only run for three latest systems, so no SDK issues are ever detected, unless someone complains on Trac. (You would think that port health will be checked from buildbots at least post factum, but no, usually no one cares.)
Besides daily broken builds, there are incompatibility breakages: something gets updated without verifying that dependents can still build with it and work or subport is removed while it has dependents. I think, recently was a third time when I fixed Deluge, broken by someone updating dependencies without maintaining coherency (and that included sorting out the mess with 5–10 dependencies).
As a bonus, often a port is broken by something completely silly: a patch is not rebased or not needed, and fails to apply, or someone fixes an issue for clang, breaking the build with gcc at the same time, etc.
Honestly, it is as bad as it can get. My rough estimate is if nothing is done for a week, something won’t work anymore, and within a month the whole set-up is largely unusable.
It will be yet worse for Tiger, for obvious reasons. Though getting gcc14 should have substantially improved the situation – my experience with 10.4 is pre-gcc14, so may be biased towards the worse.
I think, a reasonable – and feasible to follow through – approach for Tiger is to choose a few apps which you and other real-world users actually use, and update whatever in their dependency tree, once MacPorts updates that. Ideally also verify that apps still work and not just build (this is perhaps relevant for Python stuff more than anything else).
And of course, fundamental toolchain and build tools must be kept working – plus things like curl, openssh and git.
This must be perfectly doable with reasonable effort (maybe even little effort).
It may also be worth considering adopting a system of stable releases for Tiger, without requiring users to go through daily/weekly updates – with associated breakages. Like OpenBSD and NetBSD do, for example.
What I currently have with PPCPorts is a “developer snapshot”, so at any given moment something is broken until I fix it LOL.
Then sources.conf can be adjusted for Tiger, so that a single tarball of the MacPorts ports with our fixes on top is used instead of separate sources. Update that once in a quarter or smth like that, and then users won’t have bleeding-edge versions, but will have a reliably working set-up.
github.com
