is macports getting rusty?

Richard L. Hamilton rlhamil at smart.net
Mon Nov 29 12:15:59 UTC 2021


It is _possible_ to write reliable, secure code in C or even assembler. But for large complex software, it's darn unlikely; there's too many ways to mess up, even for capable and meticulous programmers, and most, even if bright and useful, aren't _that_ good.

Rust is supposed to eliminate a number of common types of problems, while still producing efficient code. So of course more projects will adopt it, and rewrite at least critical parts to use it (or something similar).

MacPorts is mainly a collection of software from elsewhere, and the mechanisms to automate installation and updates. That does not provide any control over such decisions of individual projects; MacPorts can perhaps feed bug fixes back to projects, but they don't have to accept them, and would not be likely to listen to complaints about depending on rust because of how slow it is to update

Give the developers of rust itself a piece of your mind if you like, over how slow it is to compile. Good luck with that - I suspect to be THAT slow (although really? compiling a C compiler suite plus library isn't exactly fast either) they might be doing some things by brute force that they haven't got any other good way to do - like running a serious test suite, as just one example. And of course they're the ones that suffer most over how slow it is to compile, since they have to rebuild rust every time they want to test some seemingly minor change. So I suspect they're already doing what can to speed it up that they don't think sacrifices any other concern.

A better question might be why aren't you getting/using one of the pre-built binary packages? On https://packages.macports.org/rust/ <https://packages.macports.org/rust/> I see for the latest rust version:

rust-1.56.1_3.darwin_13.x86_64.tbz2	2021-11-24 11:01	101M
rust-1.56.1_3.darwin_14.x86_64.tbz2	2021-11-24 15:46	101M
rust-1.56.1_3.darwin_15.x86_64.tbz2	2021-11-24 17:20	101M
rust-1.56.1_3.darwin_16.x86_64.tbz2	2021-11-24 14:04	101M
rust-1.56.1_3.darwin_17.x86_64.tbz2	2021-11-24 14:01	101M
rust-1.56.1_3.darwin_18.x86_64.tbz2	2021-11-24 15:54	101M
rust-1.56.1_3.darwin_19.x86_64.tbz2	2021-11-24 15:52	101M
rust-1.56.1_3.darwin_20.arm64.tbz2	2021-11-25 15:06	94M
rust-1.56.1_3.darwin_20.x86_64.tbz2	2021-11-24 10:38	100M
rust-1.56.1_3.darwin_21.arm64.tbz2	2021-11-24 08:15	94M
rust-1.56.1_3.darwin_21.x86_64.tbz2	2021-11-29 05:47	100M

Look at the dates: they don't get pre-built instantly, so if you're updating early, you won't benefit from the pre-built version. There also appears to be a single defined variant (+debug) - the pre-built packages will only be used if that variant is NOT requested. See below for equivalent macOS versions.

Darwin version		macOS version
 1			10.0 Cheetah
 5			10.1 Puma (later minor versions, at any rate)
 6			10.2 Jaguar
 7			10.3 Panther
 8			10.4 Tiger
 9			10.5 Leopard
10			10.6 Snow Leopard
11			10.7 Lion
12			10.8 Mountain Lion
13			10.9 Mavericks
14			10.10 Yosemite
15			10.11 El Capitan
16			10.12 Sierra
17			10.13 High Sierra
18			10.14 Mojave
19			10.15 Catalina
20			11 Big Sur
21			12 Monterey



> On Nov 28, 2021, at 23:37, Kastus Shchuka <macports at tprfct.net> wrote:
> 
> Dear macports users,
> 
> Recently, more and more ports began to depend on rust and cargo.
> 
> Maybe rust is a wonderful language that will solve all problems of the world. I just wonder, if it is so good, why it takes forever and a day (literally)  to compile? I've never seen anything taking that long to build. 
> 
> I've been using graphviz port for over 10 years, I guess. I had to delete it today.
> 
> graphviz depends on gd2. gd2 depends on libheif. libheif depends on rav1e. Now rav1e started depending on cargo-c, nasm, clang-13, cargo.
> An attempt to upgrade rav1e launched a build of cargo-c which I had to kill as I did not have luxary to wait for tens of hours for it to finish.
> 
> I either have to keep outdated ports or stop using them and delete. Unfortunately, the usable surface of macports started shrinking for me (or should I call it "rusting"?). 
> 
> Another example is py-cryptography, which now requires rust to build. Until binary package was made available, it took me over a day to upgrade py-cryptography. 
> 
> I also now have a broken ImageMagic because its dependency chain pulls in rust. And the list goes on and on.
> 
> I doubt people who rushed rust into macports are going to reconsider their decisions. I am just sharing my experience with this "rusting"
> 
> Thank you for reading.
> 
> -Kastus
> 

-- 
eMail:				mailto:rlhamil at smart.net




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20211129/671f772a/attachment.htm>


More information about the macports-users mailing list