@ssafar That’s not that awful. There’s software with weird enough dependencies that I really don’t want to figure out how to install the dependencies properly. Granted, extremely wrong things can and do also happen (like ad-hoc patching of files in /usr/lib :blobfoxterrified:).

If the Dockerfile is clear enough, it is self-contained recipe to install/build all the dependencies and build the software, so it can even help proper packaging downstream. I’d much rather prefer a Dockerfile that I run in reproducible manner than a bunch of unmaintained instructions in a text file, even if I ultimately wanted to install or package (AUR) a tool for my own native system.

@ssafar

This 100% made me laugh, but honestly, and Docker images are no substitute for other packages, but complex software distributed as Docker images is still often easier than the alternative.

@ssafar "well compressed" is a pretty big stretch.

Though I'll take "install via docker" over "it's super easy, just `curl | sudo sh`!" but either way, I'm almost certainly looking for an alternative since I probably don't have time to deal with your broken, poorly defined build system just to get a potentially useful new tool installed

@ssafar Exactly. Personally, I consider any software that an ordinary person cannot install other than in Docker or Flatpak is a bloatware. Unfortunately (or rather fortunately) I found out that I can't run any such bloatware, because Flatpak depends entirely on the systemd which I don't have (and don't want to have).

On the other hand, some isolation would be useful in Linux. But not in the style of Flatpak or Docker. I would rather like to see it already at the level of the packaging system: dynamic chroots would be created for each program, mixed according to it's needs (docker does something similar, but works with the whole system image, this would be at a lower level). For example, if I wanted to install nginx, the "packages" pcre, zlib, openssl, geoip, mailcap and libxcrypt would be dynamically mixed in the chroot.

Each chroot will be mounted to limit the software as much as possible (on most directories noexec, nosuid, nodev, if the exec needed, then the whole directory readonly).

Maybe there is a distribution which works like that? I think it could be possible to replace, for instance, pacman and make it to install already existing Arch linux's packages in chroots. Just re-use it's existing repositories. All you need is mount --bind, layered filesystem, and/or maybe cgroups.

And then, of course, a tool to bind shared directories into chroots - but only those needed. For instance, I would like to isolate my Firefox to only see my Download folder.

@ssafar but you can actually get a Docker image with a one liner, no? 🤔

Whereas non-containerised solutions might depend on your operating system, it's version and whether you used only its stable & supported packages or third party repositories, own builds etc.

@ssafar

@neetx