Re: librsvg, and what MacPorts is for
What is perfectly doable, done in fact with many ports (including the discussed one), and IMO should be done – provide fallbacks whenever the latest version is unfixable for the older systems. Of course, it is an open source project, and what is actually done is conditional on good will and subject to understandable constraints. I also don’t think anyone holds an opinion that the latest OS should not be prioritized. However supporting only the latest OS is a lazy maintaining which normally amounts to checksum verification. In such a case Macports would not really offer much, and becomes a download tool with delayed updates, just like Brew is. There is little value in such an approach, even more so that there is already another download tool, Brew, and offering the same shall inevitably reduce user base. Support for older systems, which is unique to Macports, keeps some developers engaged specifically with Macports, and even if end users count in dozens and not thousands, there are “positive externalities” to this: 1. People who use Macports on old systems tend to tell other people use Macports (and those use whatever systems). Why? Because they enthusiastically use Macports and see a value in it, which they don’t see in a download manager with “we-don’t-care-about-you” approach like Brew. 2. Developers who use or wish to maintain old systems provide fixes to the software (which are not limited to the OS version they use), which improves the code base for everyone. You won’t have it, if the testing is done on a couple of latest OS versions and one arch. 3. You get some software into Macports exactly because Macports supports old systems. Which then you or anyone can use on the latest OS too. Example: the only reason I brought R ports here is to make it work on PowerPC. I would not have bothered and spent several months on this, if the sole point was to support macOS-11+. And I think no one would do – and that is why Brew does not have it. However in result anyone with Sonoma can run R packages. And we have better code for R than CRAN, where they test on a few latest systems, and in result bugs are unfixed. Notice, this does not only mean that their code is broken on 10.6; some fixes I did – as a consequence – fixed Linux and BSD-affecting bugs, even that was out of my intentions. Any healthy code should work on every sane platform, and if it does not, it is broken, even if errors are obscured by ineffective testing. We do not need to have identical and even aligned goals and use-cases. What we need is the environment conducive to productive cooperation, where independent individuals are allowed to pursue their goals – the only requirement being not to harm what others do. This is exactly like a market. It should not be centrally planned, but be emergent. Then people prosper :) P. S. On a side note, it is a questionable security solution to use a single compiler which can only be built with itself. It is an ill-thought decision to dump multiple systems which do not have Rust. As a consequence, less bugs will be fixed, and the software will accumulate them over time. Yes, it may be easier to develop for people who don’t know C well enough but do know Rust. It is understandable that people try to minimize effort spent. But no, it is not something to improve security. It is, at least potentially, quite the opposite. On Oct 11, 2023 at 01:48 +0800, Perry E. Metzger , wrote: > See the following thread: > https://github.com/macports/macports-ports/pull/20744 — but to > summarize, Mascguy does not want to update librsvg to a safe / modern > one because ancient versions of MacOS can't support Rust. > > So I don't want to be a pain in the neck, but I have little interest in > MacPorts if the point is to preserve compatibility with MacOS 10.5 at > the expense of having the thousands of users of current Macs and current > MacOS have a dangerously insecure version of a basic SVG graphics > library that other things depend on. > > (The upstream librsvg maintainers have washed their hands of the old C > version and don't support it any more, and for good reason. The Rust > version of the library provides a far more secure codebase.) > > I don't know how other people feel here, but I don't work on MacPorts > because I like retrocomputing, but rather because I want to use Unix > tools on my modern Macs. > > If we're all on the same page that the priority is current MacOS users, > then we need to make sure that policy is well understood by all and we > need to update ports that are being held back for the benefit of people > using an OS from 2007. > > If the consensus is that we prioritize ancient versions of MacOS with > three users (or sometimes none) over the experience the bulk of the > users have, that's fine, and I'll accept it, but then I'm switching to > Brew, and I will advise others to do the same, and will explain that > current versions of MacPorts cannot be trusted to
Re: librsvg, and what MacPorts is for
On 11/10/2023 06:25, Perry E. Metzger wrote: That said, I presume there's a strong overall consensus that on current hardware, we run the current (supported) versions of software, and that older operating systems and hardware are supported only on a "if it doesn't hurt anything" basis. The expectation hasn't really changed since the earliest days of the project: maintainers should keep their ports working on the latest versions of macOS (roughly those that are getting security updates). Supporting anything else is going above and beyond. This is even referenced on the front page of our web site, which says we are "targeting mainly [the current releases of macOS]". Put another way, all port maintenance is best-effort, but some OS versions are more best-effort than others. :) There have been a number of previous discussions of this on the mailing lists, if anyone wants to go try to dig them up. - Josh
Re: librsvg, and what MacPorts is for
> > That said, I presume there's a strong overall consensus that on current > hardware, we run the current (supported) versions of software, and that > older operating systems and hardware are supported only on a "if it doesn't > hurt anything" basis. > I'm not sure this is 100% accurate, either. I think it's pretty much up to the maintainers of each individual port, but I know that at least for me, since I have some hardware that, for example, can't be upgraded beyond 10.11, I tend to maintain my ports using a "try our very best to make the current version of the software work on older macOSes" mentality (hence the existence of things like the legacysupport PortGroup). In some cases, that may mean making a version-numbered subport of an older release that still works on an older macOS, like what we have had to do with MoltenVK. Is this potentially a risk when there are security patches that only work on newer macOSes? Yes, but using an older version of macOS in and of itself can be considered a security risk, so I think it's up to the user to make the decision whether to run an out-of-date version of some piece of software that is still being made available through MacPorts. -- Jason Liu On Tue, Oct 10, 2023 at 3:26 PM Perry E. Metzger wrote: > And Mascguy didn't seem to care to explain the situation, which I clearly > didn't understand. Okay, That makes more sense and is acceptable. > > That said, I presume there's a strong overall consensus that on current > hardware, we run the current (supported) versions of software, and that > older operating systems and hardware are supported only on a "if it doesn't > hurt anything" basis. > > Perry > > > On 10/10/23 14:08, Gregorio Litenstein wrote: > > In general terms I (who am absolutely nobody) agree with you, but there's > one thing I believe you're not taking into account and it's that this is a > fallback version for users with ancient hardware. > > The main `librsvg` port is currently at `2.56.3`, which was released two > months ago > > @Chris, I belive OP didn't realize it's not the main port. > > > Gregorio Litenstein Goldzweig [image: glit_qr_4.png] > Médico Cirujano > > >- Fono: +56 9 96343643 >- E-Mail: g.litenst...@gmail.com > > > On 10 Oct 2023 15:07 -0300, Chris Jones > , wrote: > > Hi, > > I am not sure what you are complaining about. Version 2.56.3, whilst not > the absolute latest version a pretty up to date rust based version, is > already used on Darwin 10 and newer. Your mail below seems to imply the old > C version is used everywhere, which just isn't the case. What am I missing > here ? > > Chris > > On 10 Oct 2023, at 6:48 pm, Perry E. Metzger > wrote: > > See the following thread: > https://github.com/macports/macports-ports/pull/20744 — but to summarize, > Mascguy does not want to update librsvg to a safe / modern one because > ancient versions of MacOS can't support Rust. > > So I don't want to be a pain in the neck, but I have little interest in > MacPorts if the point is to preserve compatibility with MacOS 10.5 at the > expense of having the thousands of users of current Macs and current MacOS > have a dangerously insecure version of a basic SVG graphics library that > other things depend on. > > (The upstream librsvg maintainers have washed their hands of the old C > version and don't support it any more, and for good reason. The Rust > version of the library provides a far more secure codebase.) > > I don't know how other people feel here, but I don't work on MacPorts > because I like retrocomputing, but rather because I want to use Unix tools > on my modern Macs. > > If we're all on the same page that the priority is current MacOS users, > then we need to make sure that policy is well understood by all and we need > to update ports that are being held back for the benefit of people using an > OS from 2007. > > If the consensus is that we prioritize ancient versions of MacOS with > three users (or sometimes none) over the experience the bulk of the users > have, that's fine, and I'll accept it, but then I'm switching to Brew, and > I will advise others to do the same, and will explain that current versions > of MacPorts cannot be trusted to have safe software because the people > involved prioritize support for ancient versions of the operating system. > > I will accept whatever the consensus is. > > Perry > > >
Re: librsvg, and what MacPorts is for
And Mascguy didn't seem to care to explain the situation, which I clearly didn't understand. Okay, That makes more sense and is acceptable. That said, I presume there's a strong overall consensus that on current hardware, we run the current (supported) versions of software, and that older operating systems and hardware are supported only on a "if it doesn't hurt anything" basis. Perry On 10/10/23 14:08, Gregorio Litenstein wrote: In general terms I (who am absolutely nobody) agree with you, but there's one thing I believe you're not taking into account and it's that this is a fallback version for users with ancient hardware. The main `librsvg` port is currently at `2.56.3`, which was released two months ago @Chris, I belive OP didn't realize it's not the main port. Gregorio Litenstein Goldzweig glit_qr_4.png Médico Cirujano * Fono: +56 9 96343643 * E-Mail: g.litenst...@gmail.com On 10 Oct 2023 15:07 -0300, Chris Jones , wrote: Hi, I am not sure what you are complaining about. Version 2.56.3, whilst not the absolute latest version a pretty up to date rust based version, is already used on Darwin 10 and newer. Your mail below seems to imply the old C version is used everywhere, which just isn't the case. What am I missing here ? Chris On 10 Oct 2023, at 6:48 pm, Perry E. Metzger wrote: See the following thread: https://github.com/macports/macports-ports/pull/20744 — but to summarize, Mascguy does not want to update librsvg to a safe / modern one because ancient versions of MacOS can't support Rust. So I don't want to be a pain in the neck, but I have little interest in MacPorts if the point is to preserve compatibility with MacOS 10.5 at the expense of having the thousands of users of current Macs and current MacOS have a dangerously insecure version of a basic SVG graphics library that other things depend on. (The upstream librsvg maintainers have washed their hands of the old C version and don't support it any more, and for good reason. The Rust version of the library provides a far more secure codebase.) I don't know how other people feel here, but I don't work on MacPorts because I like retrocomputing, but rather because I want to use Unix tools on my modern Macs. If we're all on the same page that the priority is current MacOS users, then we need to make sure that policy is well understood by all and we need to update ports that are being held back for the benefit of people using an OS from 2007. If the consensus is that we prioritize ancient versions of MacOS with three users (or sometimes none) over the experience the bulk of the users have, that's fine, and I'll accept it, but then I'm switching to Brew, and I will advise others to do the same, and will explain that current versions of MacPorts cannot be trusted to have safe software because the people involved prioritize support for ancient versions of the operating system. I will accept whatever the consensus is. Perry
Re: librsvg, and what MacPorts is for
In general terms I (who am absolutely nobody) agree with you, but there's one thing I believe you're not taking into account and it's that this is a fallback version for users with ancient hardware. The main `librsvg` port is currently at `2.56.3`, which was released two months ago @Chris, I belive OP didn't realize it's not the main port. Gregorio Litenstein Goldzweig Médico Cirujano • Fono: +56 9 96343643 • E-Mail: g.litenst...@gmail.com On 10 Oct 2023 15:07 -0300, Chris Jones , wrote: > Hi, > > I am not sure what you are complaining about. Version 2.56.3, whilst not the > absolute latest version a pretty up to date rust based version, is already > used on Darwin 10 and newer. Your mail below seems to imply the old C version > is used everywhere, which just isn't the case. What am I missing here ? > > Chris > > > On 10 Oct 2023, at 6:48 pm, Perry E. Metzger wrote: > > > > See the following thread: > > https://github.com/macports/macports-ports/pull/20744 — but to summarize, > > Mascguy does not want to update librsvg to a safe / modern one because > > ancient versions of MacOS can't support Rust. > > > > So I don't want to be a pain in the neck, but I have little interest in > > MacPorts if the point is to preserve compatibility with MacOS 10.5 at the > > expense of having the thousands of users of current Macs and current MacOS > > have a dangerously insecure version of a basic SVG graphics library that > > other things depend on. > > > > (The upstream librsvg maintainers have washed their hands of the old C > > version and don't support it any more, and for good reason. The Rust > > version of the library provides a far more secure codebase.) > > > > I don't know how other people feel here, but I don't work on MacPorts > > because I like retrocomputing, but rather because I want to use Unix tools > > on my modern Macs. > > > > If we're all on the same page that the priority is current MacOS users, > > then we need to make sure that policy is well understood by all and we need > > to update ports that are being held back for the benefit of people using an > > OS from 2007. > > > > If the consensus is that we prioritize ancient versions of MacOS with three > > users (or sometimes none) over the experience the bulk of the users have, > > that's fine, and I'll accept it, but then I'm switching to Brew, and I will > > advise others to do the same, and will explain that current versions of > > MacPorts cannot be trusted to have safe software because the people > > involved prioritize support for ancient versions of the operating system. > > > > I will accept whatever the consensus is. > > > > Perry > > > >
Re: librsvg, and what MacPorts is for
Hi, I am not sure what you are complaining about. Version 2.56.3, whilst not the absolute latest version a pretty up to date rust based version, is already used on Darwin 10 and newer. Your mail below seems to imply the old C version is used everywhere, which just isn't the case. What am I missing here ? Chris > On 10 Oct 2023, at 6:48 pm, Perry E. Metzger wrote: > > See the following thread: > https://github.com/macports/macports-ports/pull/20744 — but to summarize, > Mascguy does not want to update librsvg to a safe / modern one because > ancient versions of MacOS can't support Rust. > > So I don't want to be a pain in the neck, but I have little interest in > MacPorts if the point is to preserve compatibility with MacOS 10.5 at the > expense of having the thousands of users of current Macs and current MacOS > have a dangerously insecure version of a basic SVG graphics library that > other things depend on. > > (The upstream librsvg maintainers have washed their hands of the old C > version and don't support it any more, and for good reason. The Rust version > of the library provides a far more secure codebase.) > > I don't know how other people feel here, but I don't work on MacPorts because > I like retrocomputing, but rather because I want to use Unix tools on my > modern Macs. > > If we're all on the same page that the priority is current MacOS users, then > we need to make sure that policy is well understood by all and we need to > update ports that are being held back for the benefit of people using an OS > from 2007. > > If the consensus is that we prioritize ancient versions of MacOS with three > users (or sometimes none) over the experience the bulk of the users have, > that's fine, and I'll accept it, but then I'm switching to Brew, and I will > advise others to do the same, and will explain that current versions of > MacPorts cannot be trusted to have safe software because the people involved > prioritize support for ancient versions of the operating system. > > I will accept whatever the consensus is. > > Perry > >
librsvg, and what MacPorts is for
See the following thread: https://github.com/macports/macports-ports/pull/20744 — but to summarize, Mascguy does not want to update librsvg to a safe / modern one because ancient versions of MacOS can't support Rust. So I don't want to be a pain in the neck, but I have little interest in MacPorts if the point is to preserve compatibility with MacOS 10.5 at the expense of having the thousands of users of current Macs and current MacOS have a dangerously insecure version of a basic SVG graphics library that other things depend on. (The upstream librsvg maintainers have washed their hands of the old C version and don't support it any more, and for good reason. The Rust version of the library provides a far more secure codebase.) I don't know how other people feel here, but I don't work on MacPorts because I like retrocomputing, but rather because I want to use Unix tools on my modern Macs. If we're all on the same page that the priority is current MacOS users, then we need to make sure that policy is well understood by all and we need to update ports that are being held back for the benefit of people using an OS from 2007. If the consensus is that we prioritize ancient versions of MacOS with three users (or sometimes none) over the experience the bulk of the users have, that's fine, and I'll accept it, but then I'm switching to Brew, and I will advise others to do the same, and will explain that current versions of MacPorts cannot be trusted to have safe software because the people involved prioritize support for ancient versions of the operating system. I will accept whatever the consensus is. Perry
CI for R ports broken by latests commits to mpbb
Could someone who understands what mpbb scripts are doing address this? https://trac.macports.org/ticket/68408 We got numerous R ports broken by this on CI. (Locally everything works fine, buildbot apparently too.) I can’t keep updating R ports unless this is fixed. It is too much of a meaningless time-waste to run endless CI, find out what is broken, exclude those updates from PRs, run again. Everything was working pretty much perfectly for many months until recently. P. S. Initially I thought the issue was caused by a sudden migration to libgcc13 – but apparently that was a coincidence. Every failure either complains about non-existent cyclic dependencies (possibly confusing test deps with build deps, at least in some cases) or about activation of some dependency with a non-transparent message, pointing to mpbb. Even some ports unrelated to R failed in this manner: for example, libiconv (which I did not touch at all).
