RGBCube/Site
1
Fork 0
mirror of https://github.com/RGBCube/Site synced 2025-07-29 20:17:46 +00:00
Code Issues Activity Actions

dump(build-systems.no-gnulib): update

Browse source
This commit is contained in:
RGBCube 2025-07-20 00:06:23 +03:00
parent e1c05dc85a
commit a851f5b317
Signed by: RGBCube
SSH key fingerprint: SHA256:CzqbPcfwt+GxFYNnFVCqoN5Itn4YFrshg1TrnACpA5M
1 changed files with 24 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

30
site/dump/build-systems/no-gnulib.md
View file

@ -4,6 +4,11 @@ description: ...and Debian.
date: 2025-07-19
---
If you are a GNU maintainer and are not willing to be critizied by people sick
of your bullshit software, do not read this post.
---
# Say NO to Gnulib
The commonly overlooked but also very important argument for dropping GNU
@ -20,11 +25,11 @@ shrivel in pain & makes packagers go bald & makes issues hard to diagnose and
debug.
It's so ass. It's so incredibly easy to build it wrong and create a shitty
distro (and it is built _wrong_ by default). At least in Rust and the general
ecosystem of Rust, `Cargo.toml` is pretty well-defined and `build.rs` scripts
don't do anything that insane. (Hell, even the
[C compilation tools used inside crates](https://lib.rs/cc) are shared deps and
is well-defined).
distro (and it is built _wrong_ by default). At least in Rust (or in other
ecosystems, such as Go) and the general ecosystem of Rust, `Cargo.toml` is
pretty well-defined and `build.rs` scripts don't do anything that insane. (Hell,
even the [C compilation tools used inside crates](https://lib.rs/cc) are shared
deps and is well-defined).
I don't trust the average distro to build any toolchain made by GNU properly,
and I do not trust them to produce a proper set of system tools eiyher because
@ -39,6 +44,11 @@ easier to audit too & it doesn't misbehave or segfault.
I hope Uutils coreutils & Uutils findutils and so on achieves near perfect
compliance so I do not need to serve GNU tools to my users.
> Also, keep in mind that it doesn't have to be Rust. I would also welcome the
> GNU people fixing up their shitty build tooling & making their software behave
> correctly. But that isn't happening any time soon, so we are starting from
> scratch & fixing (quite) a few itches on the way.
Read more about this on the
[Sortix wiki.](https://gitlab.com/sortix/sortix/-/wikis/Gnulib)
@ -73,7 +83,7 @@ Incredibly foolish. You are not supposed to package every single crate manually,
and you should not be anyway.
The way you should package any programming language that has a widely used and
generally well-defined and static build system is to generate package
generally well-defined and static build system is to generate (unlisted) package
definitions from packages using a script or tool (such as
`cargo metdata -> parse json -> puke out package manifests`), and only add extra
configuration to packages that depend on anything external (such as a C library,
@ -118,6 +128,14 @@ dependencies will be configured in a
so a top-level Rust program that uses a crate that requires `liburing` won't
actually see `liburing` when being compiled.
And here's another great part: Since the `pkgs` view is not a 1:1 map of all the
derivations (build units, but in a fancy Nix / Functional Software Deployment
Model way), these generated definitions won't pollute search or interfere with
users. It's just a plus in almost every way imagineable.[^A negative would be
the sandbox creation overhead of `nix-daemon`, but that shouldn't be significant
most of Rust builds from scratch, and for those that are, the already-cached
crates will mitigate the losses pretty easily.]
<blockquote>
You can actaully use this right now with