
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Jan 13, 2022, at 23:15, Ryan Schmidt <ryandesign@macports.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>On Jan 13, 2022, at 17:01, Bill Cole wrote:</span><br><span></span><br><blockquote type="cite"><span>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:</span><br></blockquote><blockquote type="cite"><span>[...]</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>My question for y'all goes like this - How long will macports continue to "work" on Mojave?</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>No one can actually give a fixed date for that which you could reasonably rely upon.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>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.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>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.</span><br></blockquote><span></span><br><span>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:</span><br><span></span><br><span>https://github.com/macports/macports-base/commit/281dffca1574b5373c2161a7dfad9a4d5239e784</span><br><span></span><br><span>I don't remember exactly what it was but presumably this new feature required the use of capabilities that were introduced in Tiger.</span><br><span></span><br><span>There hasn't been any need to increase the minimum macOS version for MacPorts base since then.</span><br><span></span><br><span>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.</span><br><span></span><br><span>All that said, Mojave is not that old so hopefully you won't have too much trouble for a few years yet.</span><br><span></span><br></div></blockquote><div><br></div>forgot to reply all >< <div><br><div><div><div style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">> 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.</div><div style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Your explanation is accurate, and though I realize <b>it is easier said than done</b>, 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 <i>if a port builds, it will always build </i>– 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.</div><div style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">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.</div></div><div><br></div></div></div></body></html>