Re: Mojave and Macports
On Jan 13, 2022, at 22:33, chilli.namesake wrote: > >> 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. I can appreciate that perspective, but as you know that's not how MacPorts works in general, though it is possible for individual ports to be designed this way, to an extent. We do not have separate ports trees for each OS version. MacPorts base could easily accommodate it, the problem is just that we already do not have nearly enough contributors to keep our one ports tree up to date and working, so we certainly do not have the time to maintain separate ports trees for each OS version. For some ports, the maintainers do go to the effort of keeping old versions for old OS versions. For example, the mkvtoolnix and mame ports are aware of the limitations of older systems and downgrade to older versions on those systems. Of course, that doesn't address the problem of any of those ports' dependencies increasing their system requirements over time. Although the intended way to use MacPorts on any system is to use the current version of MacPorts and the current ports tree, we do publish snapshots of the ports tree when we release new major versions of base: https://github.com/macports/macports-ports/tags So someone could conceivably download an older ports collection and an older version of MacPorts base if they wanted to experience MacPorts as it was at a previous point in time, such as at a time when a different OS version was current and better supported. This is of course no guarantee that that older set of ports would work better on the older system. In many cases, our current ports tree probably works better than an old one as we continue to update ports to fix bugs and refine our legacy support library and our collection of compilers and other tools.
Re: Mojave and Macports
On 1/13/22 5:01 PM, 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. Thanks for the response. I thought it was something along these lines, but its reassuring to hear. My Snow Leopard host, an old iMac, died before the lack of support got too bad. My laptop will hopefully hold out a while longer. It's kinda funny, but for a 10 year old machine, it' still quite respectable and is actually more capable than my 2021 MacBook Pro M1 which can't even do virtual box.
Re: Mojave and Macports
> On Jan 13, 2022, at 23:15, Ryan Schmidt 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.
Re: Mojave and Macports
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.
Re: Mojave and Macports
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. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Mojave and MacPorts update
On Aug 15, 2019, at 14:05, Chris Jones wrote: > On 15 Aug 2019, at 6:44 pm, Ryan Schmidt wrote: > >>> On Aug 15, 2019, at 12:36, Bill Stackhouse wrote: >>> >>> :info:build /opt/local/bin/ranlib: object: .libs/libapr-1.a(apr_encode.o) >>> malformed object (unknown load command 1) >> >> This means your cctools port is too old to understand what's coming out of >> the compiler. Try reinstalling the cctools port with the +xcode variant. > > Note that the xcode variant is no longer the default. i would recommend > instead just using the current defaults of cctools. If that works, sure. But the xcode variant is the only variant that effectively changes the version of the software provided. Without the xcode variant, the port builds a cctools version comparable to that shipped with Xcode 10.0. If the code produced by the compilers in the current more-recent version of Xcode is no longer compatible with the cctools software from Xcode 10.0, then using default variants will not work, and the xcode variant will have to be used, until such a time as Apple releases a newer version of the cctools source code and the cctools port is updated to that version. Or you could be right. It could be that it's the llvm version that matters, and building cctools with an older llvm variant will not work with the object files produced by newer Xcode's compilers. If that's the case, then just using a newer llvm variant is the solution.
Re: Mojave and MacPorts update
> On 15 Aug 2019, at 6:44 pm, Ryan Schmidt wrote: > > > >> On Aug 15, 2019, at 12:36, Bill Stackhouse wrote: >> >> :info:build /opt/local/bin/ranlib: object: .libs/libapr-1.a(apr_encode.o) >> malformed object (unknown load command 1) > > This means your cctools port is too old to understand what's coming out of > the compiler. Try reinstalling the cctools port with the +xcode variant. Note that the xcode variant is no longer the default. i would recommend instead just using the current defaults of cctools. Chris
Re: Mojave and MacPorts update
Thanks Ryan. That solved the problem. Bill > On Aug 15, 2019, at 10:44 AM, Ryan Schmidt wrote: > > > > On Aug 15, 2019, at 12:36, Bill Stackhouse wrote: >> >> :info:build /opt/local/bin/ranlib: object: .libs/libapr-1.a(apr_encode.o) >> malformed object (unknown load command 1) > > This means your cctools port is too old to understand what's coming out of > the compiler. Try reinstalling the cctools port with the +xcode variant.
Re: Mojave and MacPorts update
On Aug 15, 2019, at 12:36, Bill Stackhouse wrote: > > :info:build /opt/local/bin/ranlib: object: .libs/libapr-1.a(apr_encode.o) > malformed object (unknown load command 1) This means your cctools port is too old to understand what's coming out of the compiler. Try reinstalling the cctools port with the +xcode variant.
