showing dependency trees

[Jeff Spaleta]

2009/8/24 Björn Persson <bjorn at xn--rombobjrn-67a.se>:
> On the other hand, not addressing such situations at all ultimately leads to a
> huge tangle where every single package depends on pretty much all of Fedora
> Everything. It's a matter of finding a good balance.

Are you suggesting that things are out of balance now?  What is an
allowable amount of tangle?  Aren't you making an assumption that we
are out of balance? Define a prescriptive "good enough" threshold to
meet.  Make sure you include a cost function for the associated
repository metadata increase and subpackage header for each subpackage
you add.

>
> Splitting every library binary into its own subpackage might not always
> resolve the situation by the way. I have seen libraries that lump together all
> sorts of unrelated functions in a single .so file.

Are you seriously suggesting expending the manpower at the
distribution level to poke at which functional calls need to broken
out into more libraries? One function per library! One library per
subpackage!

There are also libraries
> written in interpreted languages that aren't compiled into binaries, and in
> some cases the dependencies might not even be libraries at all.

I'm fully aware of the difficulty with interpreted languages.  And do
you know which percent of those are explicit and which are
auto-generated via a buildtime dependency generator?  Explicit deps
and provides are quite fragile..that's not going to change. The win is
going to come from automating as much of the depchain in interpreted
languages as possible instead of systematically trying to fix
explicitly coded deps one package at a time.

-jef