sane dependencies -- a positive look at 'fix your packages'

[Mike Hearn]

On Sun, 2003-10-12 at 00:40, Havoc Pennington wrote:
> which is the general approach for
> avoiding "dependency hell" used by Windows/Mac.

Mmm. I have a feeling it simply replaces it with other types of hell. On
MacOS X the glacial rollout of weak symbols mean that apps frequently
depend on point releases of the whole OS. On Windows, the situation is
somewhat better, but only because Microsoft release updates for OSs that
are over 5 years old.

> To clarify dependency hell; if by that one simply means having to find
> dependencies and install them, then you either internalize
> non-core-platform deps, or you have external dependencies. That tradeoff
> will never go away. Best you can do is have tools such as
> yum/up2date/apt to simplify things.

Of course that's correct, but the problem is people have used tools like
apt and see that they work well, and are convenient. They want them to
work well all the time, instead of just some of the time. I think
boosting the success rate of these types of tools is certainly doable.

> If by dependency hell one means having to choose between set of apps
> requiring library Foo version 1 and set of apps requiring library Foo
> version 2, the solution to that is also known:
> http://ometer.com/parallel.html and/or "compat" packages and soname
> changes.

Right - I wasn't really meaning this, but parallel installability is
clearly an educational issue.

> I don't believe the packaging format (RPM vs. whatever) has a *thing* to
> do with it. RPM allows you to express dependencies to automated tools.
> However, it doesn't _create_ the dependencies; you are free to have them
> or not as you see fit. So blaming dependency hell on RPM is just
> shooting the messenger. 

It's reasonable that RPM gets beat up a bit - this particular messenger
sometimes gets it wrong (for instance when you install from source).

Perhaps some of the blame lies with developers for going overboard with
dependencies, but perhaps also it is up to us to technically manage this
situation better (which I think can be done).

thanks -mike