Usage of Homebrew as software installation solution to avoid transactional update

[victoitor]

Small introduction which is not necessary to the topic

I love the concept of Aeon, tried it, had issues and decided to try again when it's released. On the meantime, I decided to try Bluefin. At the same time, it's clear to see both similarities and differences between these two projects. For people who are not aware, the main similarity is to build a desktop that is always updated and never breaks and this is done with atomic updates and snapshots (by different means) and usage of containerisation (flatpaks and distroboxes). The main differences are a minimalistic approach by Aeon and a very opinionated list of installed apps and services by bluefin.

I have also seen @sysrich in one of his talks mentioning the differences in view and a complaint that Aeon is following it's own thing. It might be a recurring topic which can be super annoying which led me to not touch this subject before. Telegram also has a rule for it:

5. “The Silverblue Rule”. Any request or discussion that cites any other Linux distribution to support or justify that request will be deprioritised as a result. Any good idea should have reasons besides just following others.

Although this idea is created as a solution to my issues as I understand how bluefin works, I think this post does follow the Silverblue rule in the sense that my reasoning is not just for "following others". I decided to share as I prefer the Aeon approach and think this may be a positive thing.

I made a post about using Aeon for a computer lab for students in my university research group. The main question was on doing authentication through kanidm. I am a professor at a small and underfunded university in Brazil and the professors have to build these solutions themselves so this is my attempt to improve the situation for our students.

According to the Software Installation wiki, I think this solution requires it to be installed in the Transactional Update level, which should be avoided if possible to keep a clean underlying system. At the same time, I saw that kanidm can be installed through homebrew. Considering how bluefin allows the installation of homebrew isolated from the base packages (it's done on home/linuxbrew), it would be an additional way to avoid doing the transactional update installation.

Would this be interesting as a last resort to not getting into transactional update territory and as a way to simplify the possible installation of binaries or is there a reason for this not to be a good solution?

[zilexa]

Yes please.
This would make Aeon much more attractive.
Look at the way Bluefin is doing it.. it's quite interesting.

[blechinger]

I see that the kanidm server runs via docker and that the kanidm client is installable via cargo, packaged for the most common package managers, and available as a docker tools container (which they recommend against using). Maybe that last item is what threw you off? I agree that running the client using the kanidm docker tools container would be clunky.

There are a few ways to get this working without having to touch transactional-update at all. I think the simplest is installing it in a distrobox and exporting the binary.

Example:

# Create a new container using an image whose package manager will include the necessary package.
~> distrobox create --image leap:latest --name kanidmTest
Creating 'kanidmTest' using image leap:latest    [ OK ]
Distrobox 'kanidmTest' successfully created.
To enter, run:

distrobox enter kanidmTest

# Enter that container.
~> distrobox enter kanidmTest
Starting container...                            [ OK ]
    ...(truncated for brevity)...
Ensuring user`s access...                        [ OK ]

Container Setup Complete!
# Install kanidm-clients.
📦[derek@kanidmTest ~]$ sudo zypper in kanidm-clients
    ...(truncated for brevity)...
# Double-check the location of the newly installed binary.
📦[derek@kanidmTest ~]$ which kanidm
/usr/bin/kanidm
# Export that binary to the host system.
📦[derek@kanidmTest ~]$ distrobox-export --bin /usr/bin/kanidm
/usr/bin/kanidm from kanidmTest exported successfully in /home/derek/.local/bin.
OK!
# Exit the container.
📦[derek@kanidmTest ~]$ exit
logout
# Double-check the location of the exported binary.
~> which kanidm
/home/derek/.local/bin/kanidm
# Run the binary from the host system as if it were a natively installed package.
~> kanidm help
Kanidm Client Utility

Usage: kanidm [OPTIONS] <COMMAND>

Commands:
  login            Login to an account to use with future cli operations
    ...(truncated for brevity)...
  help             Print this message or the help of the given subcommand(s)

Options:
  -d, --debug                       Enable debugging of the kanidm tool [env: KANIDM_DEBUG=]
    ...(truncated for brevity)...
  -h, --help                        Print help

The specific steps will depend on which image and install method you choose. The generalized workflow outlined above is what I'd recommend for most non-flatpak things (even GUI apps).

If we take a look at our "exported binary" we can see it's actually a shell script:

#!/bin/sh
# distrobox_binary
# name: kanidmTest
if [ -z "${CONTAINER_ID}" ]; then
        exec "/usr/bin/distrobox-enter"  -n kanidmTest  --  '/usr/bin/kanidm'  "$@"
elif [ -n "${CONTAINER_ID}" ] && [ "${CONTAINER_ID}" != "kanidmTest" ]; then
        exec distrobox-host-exec '/home/derek/.local/bin/kanidm' "$@"
else
        exec '/usr/bin/kanidm' "$@"
fi

So when we run kanidm from the host we're actually using distrobox to run the binary from within the container and passing arguments to it. Distrobox makes it appear seamless so you don't really need to know this in order to use it... But I think it's worth noting. 🙂