That’s exactly what the package management system does in distributions. And a maintainer (or group), actually all admins and users, are looking after the same single current line of packages. (Not after multiple diverse container universes.)
Why would you want to burden all that on the shoulders of the application developer?
I think the app devs should not be required to support more than their own app (i.e. not have to make timely security-updates available for every lib they use in every flavor of container).
I don’t think there is only the container way. The reason why containers are often used is to work around properly supporting fast paced app development with breaking version changes in the app dependencies. That, however, is something that also seems to get tackled by FastTrack - Debian Wiki in debian. (Besides the nix and guix package managers.)
So the best seems to be, that for web-applications the existing debian/yunohost already has manifest and shell helper based packages, even linters are already a real, self-hosting “thing that works”, and it would be great if new developments could allow it to be turned it into a more general solution.
A collection of packages might be one “thing that works”, but not just one in a distro package management scope.
It’s easy to understand: you have one app that requires version 1 of libx, and have other app that requires version 2. You can’t have both because the system just packages one, unless you upgrade your whole system to a new version, which has more implications in the full system stack.
Containerizing decouples the system and apps, making updating both easier.
I may not have expressed it well enough. Yes, the container overhead is often used just to install and use some different versions of the same software, but I think that does not mean that no simple ways exists, have or will emerge (versioned directories+separate repository, lxroot, bedrocklinux, …) which can avoid the container drawbacks.
Could you please make, or do you already have, information available somewhere about your package spec improvement ideas and plans? (@ljf and others)
Sidenote about not depending on every app developer or packager of all the apps to apply updates to every library they containerized somewhere (instead of facilitating the common distribution maintenance):
I’d say containerizing actually couples every app with a specific system environment (all tools and libraries in the app’s container system) in addition to coupling with the peculiar host system’s container management facilities and conventions. Instead of only using a standard init system. (Creating a dependency hell for maintaining properly updated systems. And in practice leading to much outdated code that continues to run with known vulnerabilities in a lot of containers that have once been published, many even with really unsure maturity and quality control to begin with.)
These blog posts may provide some glimpses about things involved in implementing a solution for proper app-specific environment handling: