> On Jan 13, 2022, at 23:15, Ryan Schmidt <ryandes...@macports.org> wrote: > > On Jan 13, 2022, at 17:01, Bill Cole wrote: > >> On 2022-01-13 at 16:26:01 UTC-0500 (Thu, 13 Jan 2022 15:26:01 -0600) Will >> Senn is rumored to have said: >> [...] >>> >>> My question for y'all goes like this - How long will macports continue to >>> "work" on Mojave? >> >> No one can actually give a fixed date for that which you could reasonably >> rely upon. >> >> MacPorts still has support for Tiger. That's 10 releases older than Mojave. >> It is unlikely that the aggregate 'vision' of the people doing the work of >> keeping MP going will change so much as to drop Mojave before it is simply >> impossible to continue to support it. If I recall correctly, dropping >> Panther only happened because the last Panther-capable machine available to >> the project died. Speaking only as a long-time user and observer of >> MacPorts, I would be surprised if Mojave support went away in this decade. >> >> With that said, "support" in MacPorts' core is not the only thing to be >> concerned with. One thing I found running Snow Leopard until last February >> on a 32bit-only CoreDuo was that support in ports I was using or tried to >> use was slowly crumbling over time, often beyond anything MacPorts could >> work around. The biggest headaches weren't even rooted in hardware or OS >> version per se, but in the toolchain (gcc/clang/etc.) and runtime >> (libgcc/libcxx/etc.) evolution. Re-bootstrapping my whole MacPorts world >> never became impossible, but by the end it was a multi-day festivity >> involving building multiple toolchains and learning obscure command-line >> options for port. It may never become impossible for to keep using MacPorts >> on Mojave, but it may end up taking so much babysitting that you'd rather >> not. I hope that's a long time, because my personal machines are staying >> there for some time as well. > > Mac OS X 10.4 became the minimum requirement for MacPorts base in version > 1.8.0 back in 2009 due to the addition of the new privilege dropping feature: > > https://github.com/macports/macports-base/commit/281dffca1574b5373c2161a7dfad9a4d5239e784 > > I don't remember exactly what it was but presumably this new feature required > the use of capabilities that were introduced in Tiger. > > There hasn't been any need to increase the minimum macOS version for MacPorts > base since then. > > The minimum OS version for ports, however, is a constantly moving target. > Over time, software starts breaking on older systems as developers either > intentionally or accidentally adopt features of newer systems. Sometimes we > can work around these problems, with or without the developer's help, to get > a port working again; other times we can't. The older the system, the more > difficulty you may have finding someone who has the interest in > troubleshooting the problem and who still has access to the older system. > > All that said, Mojave is not that old so hopefully you won't have too much > trouble for a few years yet. >
forgot to reply all >< > Sometimes we can work around these problems, with or without the developer's > help, to get a port working again; other times we can't. Your explanation is accurate, and though I realize it is easier said than done, this shouldn't happen. It is a deficiency and I don't know that it can be solved, but I wish it were so that if a port builds, it will always build – that package management should be aware of what system version it is running on and at some point cut off that system version from current releases so it can only grab ports that are known run on that system, or the last known port version that works. A package manager shouldn't break the older systems no matter what changes or advances are made. It should "know" and not attempt builds that can never successfully compile. Again, I realize this is a tricky specification to tack on 20 years later, esp. because ports wasn't designed with this spec and MacPorts is based on ports. But I think it would be a worthy achievement if someone can figure out a clever way to do it that does not place extraordinary burden the developers.
