Debian dependency maps
![[Emacs map]](https://static.lwn.net/images/ns/emacs21_depmap.png)
Some folks at gnowledge.org have put together a
tool to generate graphical dependency maps for packages in the Debian
distribution. At the right is a (much condensed) map for emacs. For some
real amusement, go to the map generator
and get a map for a package like amarok.
Posted Dec 17, 2008 21:25 UTC (Wed)
by fjpop (guest, #30115)
[Link] (1 responses)
Posted Dec 18, 2008 18:57 UTC (Thu)
by ajensen (guest, #47536)
[Link]
See also: debgraph
debgraph's focus is on identifying dependency cycles and producing graphs of the packages in each cycle, but its API is generic enough to produce results similar to those in the article with a few lines of Lua.
Posted Dec 17, 2008 21:30 UTC (Wed)
by halla (subscriber, #14185)
[Link] (5 responses)
Posted Dec 17, 2008 21:39 UTC (Wed)
by kragil (guest, #34373)
[Link] (4 responses)
Posted Dec 18, 2008 18:34 UTC (Thu)
by drag (guest, #31333)
[Link] (3 responses)
Posted Dec 20, 2008 14:50 UTC (Sat)
by epa (subscriber, #39769)
[Link] (2 responses)
This entanglement could be broken by having conditionalized 'provides' specifications. So currently you might have a package 'foo' stating the following (I am making up the syntax):
Posted Dec 21, 2008 10:14 UTC (Sun)
by ldo (guest, #40946)
[Link] (1 responses)
epa wrote: This entanglement could be broken by having conditionalized 'provides' specifications. Sounds like you want something similar to Gentoo-style USE-flags.
Posted Dec 23, 2008 17:58 UTC (Tue)
by epa (subscriber, #39769)
[Link]
There are other tools, though not web-based, that can do the same and
that provide more information. One such tool is debtree. Other examples
are apt-cache dotty and apt-rdepends --dotty.
Debian dependency maps
Debian dependency maps
Debian dependency maps
heartened. We must be getting good at "standing on the shoulders of giants"
to be able to use and reuse so much work.
Debian dependency maps
But all those arrows should get different colors. Otherwise it gets really confusing.
Debian dependency maps
http://www.gnowledge.org/debmap_view?objid=gnome-panel
This shows the crazy results that are possible when you interpret dependencies too strictly. Does gnome-panel really depend on /usr/bin/python? I assume not, but there is a chain of dependencies leading back.
Debian dependency maps
requires: perl python ruby
provides: foo-perl-bindings python-perl-bindings ruby-perl-bindings
This might be technically correct. But it means even a C program linked against libfoo will drag in perl, python and ruby. Instead the language bindings could be conditionalized 'features' which are only provided if the necessary support is enabled:
conditional (requires: perl) {
provides: foo-perl-bindings
}
conditional (requires: python) {
provides: foo-python-bindings
}
conditional (requires: ruby) {
provides: foo-ruby-bindings
}
That way, apt-get or yum or whatever would know to install both foo and perl to satisfy the dependency foo-perl-bindings, but perl would not be necessary just for a C program linked against libfoo.
I would imagine this mechanism could drastically trim the dependencies for a package like gnome-panel.
Conditionalized?
Conditionalized?
Sounds like you want something similar to Gentoo-style USE-
flags.
Something like that, but without the complication of
building several different variants of a package. Just one package, but
the features it provides depend on what else is installed. For example
Perl's http library will also provide https, but only if SSL libraries are
installed. On the other hand an app which just needs to download plain
http web pages does not need those libraries. So there should be a
conditionalized Provides: specification, but it is not necessary to rebuild
the library with SSL support (it's detected at run time). This is more
common with interpreted languages than with C or C++ programs.