Log in

Software packaging, and the 10 × 10 problem - James Antill

Jun. 20th, 2007

05:09 am - Software packaging, and the 10 × 10 problem

Previous Entry Share Next Entry


[User Picture]
Date:June 20th, 2007 02:12 pm (UTC)

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).

(Reply) (Parent) (Thread)
[User Picture]
Date:June 20th, 2007 02:40 pm (UTC)

Re: Dependancies aren't as big a problem as assumed

Right, treating apps and their deps as a group is basically what I'd like to achieve. It's easy to install a new app and pull in its dependencies automatically if you can be certain that this will not disrupt a running system. If each dependency is a separate package then you get sharing where possible.

Regarding your Evolution/gtk example, I'd say that if you are a heavy user of a gtk application then you don't want your work disrupted by a forced upgrade to the latest version just because Evolution wanted a new gtk. So the problem is not that gtk can't change, it's that you need to keep the old version around to support the important application.

The main difficulty with solving the multiple versions problem is that autoconf and libtool are built on the assumption that there's one of each thing on the system installed in a "usual" place. Fixing build scripts so that they work when you break this assumption is a tedious and soul-destroying occupation.
(Reply) (Parent) (Thread)