(Ustr, micro string API)
(and-httpd - simple, fast and secure)
(String library comparison)
A big problem is cascading dependencies, where upgrading app A pulls in an upgrade to library B which is not reliably backwards-compatible, so you have to upgrade app C to a version compiled against the new B - but you didn't want C to change.
Kind of, there are certain packages which tend to depend on newer core libraries but it's not obvious how much you'll just be able to sign off on the deps. too. For instance large GUI based ones, like evolution, often depend on newer libs. ... but I think in the real world it'd be a pretty strange requirement that you have the latest evolution but libgtk etc. can't change.
Much more likely is that you treat applications as groups with most or all of their deps. The easiest cases are things like "I've install fish, am on the mailing list and so want the latest version of that" ... or the "web developer" problem where you don't want a 2-5 year old PostgreSQL/Apache-httpd on an OS that you'd otherwise classify as "very stable".
I'm prepared to be proven wrong though :), and I do think solving the multiple versions problem (while hard) is doable … and the solution is very likely to add useful features to the package manager/distribution layer. But I might not start out trying to solve that problem first :).
I haven't heard of Nix, although I have played with rPath a bit and that's a significant step forward. I'd looked at OpenPKG before and the "pipe everything into sh" part scares me a bit, also while it seems like it has a couple of nice things for solving some of the problem it doesn't seem to attack the problem itself (so managing N slight variations of Fedora, say, wouldn't be significantly easier for the consumer or producer).
Why not "fix the problem"? Come up with an API/policy to FORCE libraries to be backwards compatible?
Even if that was "just" very hard, how would you force libraries to do it? It's like saying the solution to a problem is to get all web pages to use white text on a black background. And a lot of libraries are backwards compatible at an interface API/ABI level, but that doesn't help as sometimes the only way to be 100% backwards compatible is to not change.
Essentially, if a new function needs to be added, or an existing function must be modified, create a new function name and add it to the API. Errors in existing API functions can be corrected without renaming. Or somesuch policy.
And what do you do when the function is called from 6 other functions, that you also export ... do you now have to create 7 new functions to do a 1 line change? And then what do you do for the applications that call the function which has changed behaviour ... do they call the new function or the old one? What about for the two scripts calling the applications, one of which wants old and one new? Pretending you can solve all the problems with a single result just doesn't work.