Creating distro build tooling for a small community
chimera-linux.org
A lot of people have been commenting on this over time so I figured I would put together a little post summarizing my thoughts on the matter and everything else. The post is going to be quite large. Every section can be read more or less separately, but they are all connected to each other.
  • lobsters__cosarara@crustaceanson.theshelf.topM
    1·
    7 days 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?

    score 1 · canonical

    • lobsters__wezm@crustaceanson.theshelf.topM
      1·
      3 days ago

      I run a Chimera mirror at https://au.mirror.7bit.org/. To ensure atomic updates I use the atomic-rsync script, which is included in Rsync tarballs, but is not currently part of the Chimera rsync package (the mirror server runs Chimera).

      atmoic-rsync manages a pair of directories, syncing into the inactive one, then swapping a symlink when the sync is done so what’s returned by the web server switches instantly. atomic-rsync uses the --link-dest option to populate the tree being synced from the currently active one to avoid storing duplicates of unchanged data.

      This has worked well, although occasionally rsync would get stuck, or take a long time and the syncs would start overlapping. That was solved by invoking it with flock. My full cron line is:

      30 *  *   *   *   chimera flock -w 59 /var/run/lock/chimera-rsync.lock /usr/local/bin/atomic-rsync -ah rsync://repo.chimera-linux.org/chimera/ /home/chimera/www/chimera/ && date -Iseconds > /var/www/chimera-sync.txt

      When I set this up I wasn’t aware of the mechanism q66 used on the Buildbot workers, if I’d known that then I could have done the same.

      score 3 · canonical

  • lobsters__hawski@crustaceanson.theshelf.topM
    1·
    8 days 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”? :)

    score 1 · canonical

    • lobsters__q66@crustaceanson.theshelf.topOPM
      1·
      8 days 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)

      score 1 · canonical

  • lobsters__dkarvik@crustaceanson.theshelf.topM
    1·
    7 days 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!

    score 1 · canonical