I assume it doesn’t, but thought I’d ask.
I really like the principles behind both gentoo and flatpak, but right now I can only do the gentoo way or the flatpak way (and I’ve opted for gentoo’s for now).
What I’d love to have from flatpak:
- container like sandboxing and isolation
- customizable sandboxing and permissions
What I’d love to have from gentoo:
- powerful build system building packages from source
- global declarative management of compilation options
- easy patches
- easy to add packages that aren’t in repos
- support for many architectures or setups
I’ve been interested in nix for a while. In fact, the use case I described probably fits nix better than gentoo. I’ll check it out. Thanks!
Is Nix taking over? But, I am so used to Gentoo and probably will never make the switch.
At that point you might as well use a Docker type container in which to build your software from source and deploy in the container.
But Flatpak has its fancy “portals” to connect each app with the specific resource it needs which you don’t get with Docker.
Also if the goal is to limit access of apps you don’t want to fully trust, I think Docker doesn’t have the appropriate security properties. Here’s a quote from the readme for Bubblewrap (the sandboxing tool that Flatpak and Nixpak use),
Many container runtime tools like systemd-nspawn, docker, etc. focus on providing infrastructure for system administrators and orchestration tools (e.g. Kubernetes) to run containers.
These tools are not suitable to give to unprivileged users, because it is trivial to turn such access into a fully privileged root shell on the host.
in theory shouldn’t it be possible to use bubblewrap and the xdg-desktop-portal project to hack together only the sandboxing bits of flatpak while leaving out ostree/distribution
you might run into this though: https://github.com/flatpak/xdg-desktop-portal/issues/737
I don’t think Docker is comparable to bubble wrap. The latter is a lot more flexible. Docker is a pain with GUIs, and difficult to have a customizable way to “break” isolation when you need to, like having applications talk to each other or exchange files, etc.
Does Guix fit your criteria, perhaps? If you haven’t heard of it, you can think of it as Nix with a Lisp frontend.
I unfortunately am not very experienced with containerizing packages so I can’t say much, but I know you can do it; the Nonguix channel employs containers for some proprietary software.
Like Nix, Guix has all that building-from-source stuff you’d want from Gentoo. There’s recently been work on making parameterized packages (the Guix equivalent of USE flags) a thing, but it’s still work-in-progress.
Ignoring the steep upfront cost of learning it, I’d say Guix makes it incredibly easy to add your own packages. Here’s the custom packages I currently have in my dotfiles repository. I can import one to my main config file, add the package, and it gets included in my environment the next time I reconfigure it.
As for patches, I can’t make any comparisons since I’m not familiar with Gentoo, so I think a code snippet is probably better for you to judge if you’d like it.
Here's a minimal example:
(define-public custom-pkg (package (inherit pkg) (name "custom-pkg") (version (package-version pkg)) (source (origin (inherit (package-source pkg)) (patches (list (string-append (dirname (current-filename)) "/fix-some-thing.patch")))))))EDIT: Here’s the less verbose version, which you can use instead if all you’re doing is adding patches.
(define-public custom-pkg (package-with-patches pkg (list (string-append (dirname (current-filename)) "/fix-some-thing.patch"))))Not sure if this addresses your concern about multi-architecture support, but the Foreign Architectures section of the manual discusses what you can build to.
EDIT: So I was curious after posting this because usually the CLI often has much less verbose options (like
--with-inputfor replacing inputs), and I started wondering if there was any procedure that would make this simpler. Turns out there is :) I’ve included it under the example. Although, I suppose I should have mentioned you could write your own if you really wanted to.How about not changing at all your regular packages,and containerizing what you want, or as much as possible through current profiles, through firejail? And couplet that with MAC protection offered by apparmor (one can actually set firejail to always use apparmor, and then tweak particular apps not to use it if it’s too troublesome).
This way you have your provided distro packages (gentoo or sourcemage if source based distros, it doesn’t matter), and have them execute containerized. The only thing is that there are not firejail profiles for every possible piece of SW, but the vanilla list of containers is not small either.
If you’re willing to spend the time to learn how to write custom policies, SELinux can be used for this, to some extent. It’s highly customizable and can sandbox your apps, but the process of doing so is quite complicated. I wrote a small guide on custom policy management on Gentoo in another comment if you’re interested.
There’s also apparently a “sandbox” feature, but I don’t know much about it. I just write my own policies and make them as strict as possible.
As an example, my web browser can’t access my home directory or anything except its own directories, and nobody (including my own user), except root and a few select processes (gpg, gpg-agent, git, pass) can access my gnupg directory.
This only covers security/permissions, and doesn’t include many of the other benefits of containerization or isolation. You could also try KVM with libvirt and Gentoo VMs; that works pretty well (despite update times) and I did that for a while with some success.
I think it should be possible to use bwrap to sandbox programs.
Would running gentoo in a distrobox container work for you?
Build everything you use in podman or lxc
Build everything you use and ackage it in flatpak?
It’s not even that hard to build your own gentoo-based runtimes and install stuff on top of that. Fedora does offer that, too, offering fatpaks based on their own fedora based runtime + rpms.
From my understanding this doesn’t work too well for GUIs
