[FrozenCow]

The current packaging systems has problems. You cannot install just any version of any application on your system, but a lot of people want that.

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.

[otterley]

> You cannot install just any version of any application on your system, but a lot of people want that.

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.

[FrozenCow]

This could have been solved on a different level. If the right architecture was in place Steam didn't need to solve it.

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.

[otterley]

Most distributions have provisions for installing multiple major versions of a shared library (they change the package name to libfooX to accommodate this).

[kelnos]

You cannot install just any version of any application on your system, but a lot of people want that.

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.