James Antill - Post a comment
Jun. 20th, 2007
02:12 pm - Dependancies aren't as big a problem as assumed
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).