> The parent is advocating for the Slackware approach—just take whatever's in the upstreams and slam it together—but installed into a container (so all that slamming doesn't conflict with anything), and distributed as a container image.
Have you heard of Nix and NixOS? It doesn't use containers for this, but each package's tree is kept isolated from the others'.
Nix is probably the optimal package manager, but it still is a package manager, and so still encodes particular ontological choices that get made differently by different distros at different times.
In other words: I don't just want my game from ten years ago to run; I want my game from ten years ago that was built for a RHEL-alike to run on the Debian-alike I've got today (or maybe even using FreeBSD's Linux-binary support.) Nix can't give me that, except by just being the particular tool that ends up putting together the packages that go into a container-image.
Nix can be used to exactly re-instantiate the same set of files ten years later, presuming the original Nix repo you found the software on was still alive ten years later. In that way, it is similar to creating a container-image. But for this use-case, it doesn't give you anything that the container-image doesn't, while the container-image does give you an assurance that a stable (sandbox-based) interaction model was defined at the time of the image's creation, which can still be used today.
Something that intersected the Nix package-management model with the Mac App Store "only self-sandboxed apps will be accepted" model would be strictly equivalent to containers, though.
Have you heard of Nix and NixOS? It doesn't use containers for this, but each package's tree is kept isolated from the others'.
https://nixos.org/nixos/about.html