Chimera Yardstick

[i-am-linja]

Some years ago now I asked the lead dev of Chimera Linux what they thought it offered over Void. Their answer was as follows:

• Be strict by default - because it's easy to loosen things, but much harder to stricten them once they're loose and established (xbps-src violates this in many ways; cbuild uses a strict sandbox by default - disables network access past fetch stage, mounts its internal / read-only, severely restricts access from sandbox to the outer system - notably none of the actual build system runs inside the sandbox, which means it cannot leak information to the sandbox - so it can be entrusted with things like signing in one pass with the build, etc.; even beyond sandboxing, there are tons of assorted loose behaviors in xbps-src that result in technical debt that i'd like to avoid and are difficult to mitigate, despite efforts; sandboxing also has reproducibility benefits because it means the environment of the build is much more standardized, with a fixed hostname, user id, devfs, etc. so it minimizes the chance of the build behaving differently in different environments)
• While at being strict by default - always run tests when packaging by default - Void does not run unit tests for anything on its builders, while running tests helps catch bugs early on; at this point it is impossible to enable tests for things by default in Void, because the technical debt has accumulated and there would be too much stuff failing, and there's like 12k templates at this point...
• Be self-sustaining - ideally tooling should be contained to be practically usable in a standalone manner, and without leaking specifics of the official running infra into it - that means anyone should be able to take cports and set up a new infrastructure from it ideally without being particularly tied to specific external components - that makes it re-targetable and resilient (meanwhile, Void is stuck on like 10 years old version of buildbot)
• Tooling should encourage good things by making them easy, and discourage bad things by making them difficult
• If it's a pain to either write or understand something in shell, it should probably not be written in shell
• Reduce build system performance overhead (e.g. building musl on my machine with cbuild takes 9 seconds, with xbps-src 27 seconds, the actual CPU time spent is similar, except in xbps-src the overhead of the build system setup and hooks is 17 seconds, in cbuild it's 0.5 seconds, this is because xbps-src is a pile of shell with tons of global state and nobody at this point can fully understand what every hook does, and cbuild is python, has little to no global state, and is easy to follow)
• Target several CPU architectures by default and build them on actual hardware rather than cross-compiling; still support cross-compiling for user packages and bootstrapping, but do not use it for production packages, and do not insist on it if it brings excess complexity into the build or is somehow sketchy (ideally cross-built stuff should come out the same as native-built stuff)
• A package manager needs to have a dependency solver (xbps does not have one)
• A package manager needs to support triggers (i.e. reverse of hooks - scriptlets not run by a package being installed, but run when other packages' actions invoke them - xbps only supports hooks)
• An init system/service manager needs to be dependency-based and support user services out of box; the system should prefer managing things via services (user or system) over ad-hoc ways (autospawn and the likes) - systemd does this, and so far few to no non-systemd distros have cared - provide a real alternative instead of catering to reactionary/traditionalist nonsense
• Unsplit monorepo leads to accumulation of junk that nobody wants to maintain - that's why cports is divided up into main (curated, endorsed software), contrib (community maintained software with builds), experimental (where anything not meeting quality criteria or waiting for further evaluation goes) and non-free
• Do not just distribute software, but have a clear vision of what kind of stuff you want people to use, and steer the repository towards endorsing those, and do not pointlessly hold onto traditions when they block positive change; good choices > many choices

I'm curious how Void shapes up on these points some years down the line. I see that XBPS is mostly C by now, but the other points are harder to search.

[Duncaen]

Most of this is "rewrite everything," it would be nice but a lot of work especially if you can't just stop updating packages to transition to a completely new build system or something like that.

xbps has always been C, xbps-src is separate.