[angersock]

So, you've brought up another important point in the Linux/packagemanager ecosystem:

"Some app will require a feature added in lib X version Y, and they're still on Y-2."

Windows has had this solved for something like a decade. Sure, there's the much lampooned "dll hell", but honestly, Linux's solution was "lol lets upgrade things and break user apps".

There is zero excuse for apps in Linux to have library dependency issues. A package, when downloaded, should have its depended-upon libs and so's tagged. When some other application is updated and pulls in new version of the libs, the first app shouldn't ever see the update. Wouldn't that be nice?

Similarly, having a stable ABI to program against for system calls would be helpful. Users complain when their old apps break, and this is unavoidable under the current Linux development model (see http://primates.ximian.com/~miguel/texts/linux-developers.ht... for a good article on this problem).

[georgemcbay]

Windows has even solved virtually all of "dll hell" via SxS.

Linux distros would do well to implement something similar. Disk space and RAM are cheap, having a few different versions of the same DLLs is no big deal. I don't remember the last time I had a .dll problem in Windows post Vista, whereas I still run into .so issues nearly constantly in Linux distros.

[nitrogen]

Linux has versioned libraries, but distros often ship only the latest versions. Libraries usually have filenames like "liblibrary.so.x.y.z", and an application will link to "liblibrary.so.x.y" or "liblibrary.so.x". Library maintainers also get lazy with making sure that the library stays compatible within major versions, or don't update the .so version properly.