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

Havoc Pennington hp at redhat.com
Sat Oct 11 23:40:14 UTC 2003


On Sat, 2003-10-11 at 18:22, Mike Hearn wrote:
> Simply bundling everything with the app really is not acceptable,
> especially for dialup users. Example: Gaim for Linux - RPM is 1.7mb (i
> think), Gaim for Windows - self extracting EXE with GTK+ is 6.7mb

Oh, I agree. Nonetheless it's a solution to "dependency hell."

My argument: there's a tradeoff. One shouldn't whine about dependencies
unless you can live with duplication. Because you win one or the other
and you may as well suck it up and live with this reality.

> Now, you can say "Linux is a platform, which consists of libraries A, B
> and C - do not depend on anything else".

Right, this is what I mean by the placeholder term "LSB." LSB in
practice is lagging the actual platform people want to use by quite a
bit and seems to have some implementation issues as you mentioned. But
LSB is only one possible token of the type "define a core guaranteed
dependency set that will always exist, and apps must internalize
anything not in that core set" - which is the general approach for
avoiding "dependency hell" used by Windows/Mac.

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.

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.

Unfortunately the upstream maintainers of many libraries are 
uncooperative when it comes to solving this problem.

Some people seem to think there's a magic bullet here or that solutions
aren't known. I would say the solutions and tradeoffs _are_ known, and
people are just unwilling to accept them.

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. 

Havoc





More information about the fedora-devel-list mailing list