Creating distro build tooling for a small community

39 points by q66 a day ago on lobsters | 4 comments

hawski | a day ago

I use Void Linux for many years now and in the past I dabbled with a distribution project based on it so this was a very interesting post for me.

I would say that xtools lints are kinda required, because they are usually run before a package would be accepted. At least that was my experience.

Void is simple, fast and it is quite easy to make a new package for it, but it does have a few complexities hidden under a rug like with staging and triggers as mentioned in the post. I explored this area a bit wanting to make an immutable distribution I wanted to keep modification dates stable, because I aimed at reproducibility to some extent. At the same time because how simple it is it is quite easy to bootstrap it. With Python it traditionally was much worse, but I guess there are now some ways to overcome it somewhat.

Once in a while I eye other distributions and it certainly made me interested in Alpine (again) and Chimera as well. Even if I would go with an immutable distribution I would still have then rw distribution somewhere as a container.

How is Chimera for a laptop?

Does anyone know the song "Merchant of the Void"? :)

[OP] q66 | a day ago

it depends on what you mean by bootstrap; if you mean compile from source on another linux distribution, it does not make a difference (python is not a part of the stage0 bootstrap path)

if you mean bootstrap absolutely from scratch, python is one of the smaller issues, it builds very simply and has minimal and trivial dependencies that you're likely going to need already (autotools, optionally compression libraries - zlib, bz2, zstd, expat, openssl, sqlite, libffi, on most setups also libedit or readline, but that's optional too)

chimera works fine on a laptop (i'm running it on a latest panther lake laptop and everything works as expected)

cosarara | 3 hours ago

Repository syncs to the final primary mirror. First, changed packages get uploaded in one step, then indexes are replaced, and only then old packages are deleted. This is to ensure that users don’t end up with any index that contains packages not present yet.

This is very smart! But now my worry is, do secondary mirrors update in the same way, or do they just rsync from the primary mirror?

dkarvik | 16 hours ago

This is a great post, and you captured really well what makes Void so unique and lovely to engage with. Despite packaging being so high quality, it's great that there's still improvements to be had.

I would be really interested to know more about:

  1. What apk solved more specifically that xbps couldn't. You mentioned dependency resolution, is it just that it makes virtual dependencies a stronger default?
  2. This is completely tangential, but choices to use dinit and musl. Admittedly the use of musl is why I've not given chimera more time: I'm paranoid that I'll need some Linux binary to function in society (e.g. zoom) and I'll hit a wall. Runit is really neat, but nitro really shows that there's capacity to improve significantly and I would love to know how dinit was chosen and your thinking there.
  3. Did you think much about build flags, variants and even -git packages when designing your system? I do wish for a brave-bin out of curiosity, a neovim-git for practicality, etc. It's frustrating we don't have .NET packaged yet on Void, so no *arr stack. I'm wondering if Chimera is able to tackle these with its design!

It's been really nice using turnstile as part of my setup and reinforcing that systemd-less can function really well!