librsvg, and what MacPorts is for

[Sergio Had]

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 <perry at piermont.com>, 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20231011/e644563f/attachment-0001.htm>