Managing System Extensions on openSUSE MicroOS with sysextmgrcli If you are running openSUSE MicroOS, you already know the drill: the root filesystem is read...
I agree in the case of Fedora Atomic, they’ve stuck to flatpak and podman (so far, they have their system extension manager tool in the work) and have rpm layering as a fallback.
But not all atomic distros have that fallback. Universal Blue, more specifically Bluefin, does not want to allow layering at all; this is already implemented in the LTS version (though it’s just bootc, so you can build your own image to install rpms). This is also true for “distroless” models like Gnome OS (and there you don’t have any prebuilt packages to pull in even if you made your own buildstream image). So for these, you have to make-do with the package managers they provide or you’re out of luck.
In an ideal world, I think we should have a single package manager that sits on top the the OS that can handle everything: GUI apps, CLI tools, sandboxed by default but also able to be disabled completely for the apps that don’t work well with sandboxes. The closest thing we have to that right now is snap.
In an imperfect but more likely world, I would be fine with two package managers. Flatpak for GUI apps and something else for CLI tools. “Flatpak Next” could fix one issue with its unsandboxed mode. But I still haven’t found something that universally works well for CLI apps.
Podman is the classic answer, but it can be a bit annoying jumping into and out of boxes. Doesn’t work well for more “system tooling” like Tailscale that also want services.
Homebrew is a more modern suggestion and actually works pretty well. But I’m not a fan out how hijacks PATH in a way that can break OS packages (such as by making homebrew dbus and systemd used over OS versions). And last I tried, the homebrew version of tailscale didn’t work (though I have read that others did get it working).
Coldbrew is an interesting alternative to coldbrew, which uses alpine packages and doesn’t mess with PATH directly, but it does place some stuff in .local/bin that could end up overriding some binaries anyway (though not to as high a degree as homebrew, and thankfully doesn’t affect libraries). But has integration issues due to sandboxing (personally had an issue where I had an app that wanted to open my browser, but it couldn’t see my browser because of the sandbox).
I agree in the case of Fedora Atomic, they’ve stuck to flatpak and podman (so far, they have their system extension manager tool in the work) and have rpm layering as a fallback.
But not all atomic distros have that fallback. Universal Blue, more specifically Bluefin, does not want to allow layering at all; this is already implemented in the LTS version (though it’s just bootc, so you can build your own image to install rpms). This is also true for “distroless” models like Gnome OS (and there you don’t have any prebuilt packages to pull in even if you made your own buildstream image). So for these, you have to make-do with the package managers they provide or you’re out of luck.
In an ideal world, I think we should have a single package manager that sits on top the the OS that can handle everything: GUI apps, CLI tools, sandboxed by default but also able to be disabled completely for the apps that don’t work well with sandboxes. The closest thing we have to that right now is snap.
In an imperfect but more likely world, I would be fine with two package managers. Flatpak for GUI apps and something else for CLI tools. “Flatpak Next” could fix one issue with its unsandboxed mode. But I still haven’t found something that universally works well for CLI apps.