yes, they are.
> System-specific packages have no concept of C building or linking.
every day i learn something new, but this time around I’m gonna go ahead a tell you that you are very mistaken.
> Things work because of some agreement about paths + pkgconfig + others.
True. By convention, we call it “convention”, or “standard” for short, e.g. POSIX or ISO C. Call us back once you have something like that in rustland.
> This is very far from the idea of a dependency manager like cargo which is very much aware of project-specific and language features.
All good and sound, and makes total sense for userland software. But what is being discussed here is an operating system and core userland. If you can imagine that to be your “project”, such as linux or OpenBSD, maybe my tongue-in-cheek comparison of a system-wide dependency manager suddenly looks less dissimilar to cargo.
needless to say, things like Linux and OpenBSD will stay written in C for a little while longer. In case of BSD specifically, you can go as crazy as to bump and rebuild your entire system from source in place, kernel and userland. BSD is one pretty old cargo cult in that sense, and pretty cool, i might add.
> language features
right… rust 2018 edition is not really rust as of 2023, or is it? This where those pesky standards come very handy.
Go on then. Beyond RPMs ability to depend on soname, what else is there on the structure/installation/usage side (not on the building side which can include whatever scripts you want). Where are they now aware of the libraries more than tar.gz is?
That’s what we do for embedded systems, anyway. I haven’t seen much success for rust in this department, although people are clearly trying to make it work. It just keeps coming out fat and ugly. A few more decades of hard push, call me a maybe.
Do you know what riscv version of xv6 rev3 compiles to in terms of object size?
I will not spoil it for you, but it compiles to total shreds.