Users do indeed care about getting bugfixes and new features in a timely manner.
I'm not sure if this is the solution to that problem, but it would be good to have a way to make pushing packages downstream easier - decoupling the configuration/integration, testing and security code review steps.
This is a problem that the distros themselves need to fix, though, not Poettering.
A nice example is games. You want to install a game on your system without working around the package manager. That was very hard to do if you weren't on the distro that the game was build for. For instance, if the game was just released, there was little chance it would work on Debian stable...
Steam has solved this problem by using their own package manager and their own set of 'approved' libraries that other games must link to. Steam always ships with the set of 'approved' libraries, just so that it can side-step the libraries on your system.
The same is true if you want to build a piece of software that seems to be incompatible with your system: it needs a different GCC, it might need a different version of Gnome libraries.
Also, disk images aren't as simple as you make it seem. If you have a system and want to upgrade one of your applications (but leave the rest as they are!), you aren't going to like the current package management tools.
These kinds of problems happen often for a lot of people and a solution is highly appreciated. That said, the solution in the article probably isn't the best.
That's the price of shared libraries (which you're trading off for easy security updates).
If you don't like this, you're still free to run statically-linked programs.
> Steam has solved this problem by using their own package manager and their own set of 'approved' libraries that other games must link to. Steam always ships with the set of 'approved' libraries, just so that it can side-step the libraries on your system.
So it's OK for Steam to do this, but not the OS vendor? I don't follow your logic.
You can have multiple shared libraries of the same name, but different major versions. Applications that need the same version can use that same version. Applications that need different versions can use different versions. The package repository shouldn't be the conflicting factor.
My thesis is that no, a lot of people don't want that. Who are we talking about here? The "self compile from source tarball" crowd grows smaller and smaller. The kind of user that is going to want a pre-installed OS image or the like does not in general care about updates to the software they have running.
Most people just install and forget, and if it weren't for in-app auto-update, most people would never upgrade.
The funniest part is that he's using systemd as an example. That's exactly the kind of software that I want to change very rarely, and I want those changes to be vetted and integrated by someone intimately familiar with the distro I'm running. The idea that I'd run an upstream-packaged version of something like systemd is absurd.
The proposed packaging system is just another system incompatible with all the others out there.
Want a standardized system image? Build one from your distro of choice (guess what: your users don't care about that either), uninstall dpkg/rpm/whatever, make a disk image. Automate the process so it's reproducible. Done.