Frederick Bruckman <fredb@immanent.net> writes:

> > Among other things, I'm unclear on whether packages should explicitly
> > list their dependancies, or if it's OK for them to get them indirectly
> > by depending on other packages that do explicitly depend on them; as
> > examples, bonobo also depends on glib, gtk, and gnome-libs, but gets
> > them and their buildlink files indirectly.
> 
> The present situation is kind of a mess. The package tools presently
> encode the full, resolved dependency list into the binary package, so
> there's effectively no difference whether you list them explicitly or
> not. A couple of other things to keep in mind:

There's a difference for the builder. If bonobo requires libxml but
only gets it because of something else, different version dependancies
between those two packages will change whether the failure is noticed
by the pkg part of the system or the package's code. It's also
possible that the implict dependance path will go away.

I should be clear here that libxml is an "explicit dependance
implicitly included"; that is, bonobo's configure script explicitly
checks for the existence of libxml with a version > 1.8.15. 

> 1) If the binaries in your package depends on gnome-libs, bonobo &c
> indirectly, then (on ELF systems) they'll require the exact minor
> versions of those shared libraries to run, so they should all properly
> be listed in the package's Makefile (though they usually aren't).

OK, this sounds like my patch is in the right direction.

> 2) Barring a reason such as the above, you should never list the
> indirect dependencies, on the hope that one day the package tools will
> be straightened out. Just to pull something out of the air for the
> sake of argument, net/ORBit depends on devel/gindent (which has no
> shared libraries). One day, ORBit may no longer require gindent, or
> may require gindent-ORBit, so it would be wrong for the depending
> packages to list "gindent" in their DEPENDS.

Right. I'm not so concerned about implicit dependancies of that form.

        - Nathan