Comments on: Debian Dependency Map

By: Debian Project News – 12 enero del 2009. | Gustavo Pimentel's GNU/Linux Blog

Fri, 25 Jun 2010 16:47:39 +0000

[...] G. lanzo un servicio que representa graficamente la informacion sobre las dependencias de los paquetes Debian, [...]

By: Moshe Dachelet

Moshe Dachelet — Thu, 11 Mar 2010 06:53:59 +0000

Hi webmaster – This is by far the best looking site I’ve seen. It was completely easy to navigate and it was easy to look for the information I needed. Fantastic layout and great content! Every site should have that. Awesome job

By: dsgsg

dsgsg — Tue, 14 Apr 2009 01:01:11 +0000

10.

m can be solved by giving an option to the user to choose pruned and un-pruned graph.

By: Saturation in the scale-free dependency networks of free software « Gnowgi

Saturation in the scale-free dependency networks of free software « Gnowgi — Tue, 03 Feb 2009 14:05:04 +0000

[...] Gnowgi is Nagarjuna’s press « Debian Dependency Map [...]

By: gnowgi

gnowgi — Mon, 19 Jan 2009 16:58:45 +0000

Your problem can be solved by giving an option to the user to choose pruned and un-pruned graph.

By: Marcin Owsiany

Marcin Owsiany — Mon, 19 Jan 2009 09:13:43 +0000

Just a note from a maintainer’s perspective: “pruning” redundant edges might give you a graph that is nicer to look at, but loses some important information.

For example the reason I’m interested in this, is because of one of my packages (ekg2, currently in experimental). It is an instant messenger, with a ton of plugins, and (consequently) a ton of dependencies. It needs to be split into smaller packages, so that people which (for example) don’t use its GUI interface don’t need to install X Window.

I need to find a good balance, which is somewhere between:
– the current situation (single monolithic package that depends on half the archive), and
– its opposite (every plugin split into a separate package, which guarantees that you never have to install a dependency that you will not need, but with the downside of bloating the archive with a dozen of “ekg2-foo”-like packages).

I hope, that by looking at the graph, I will be able to identify clusters of dependencies, and split the package in a near-optimal way.

This means that if some edges are omitted, I will miss some important data needed to solve my problem.

Another thing is the size of the packages. It would be good if you could include some metric of “transitive size”, defined as “size of the package plus size of all its dependencies”. I guess that it would be easy if not for dependency cycles.

By: gnowgi

gnowgi — Mon, 19 Jan 2009 04:31:11 +0000

Thanks John. We will use the tool “tred” and commit at the gnowledge.org asap. But, this will solve only the graph. I am suggesting that this reduction should happen within the packages.tgz file. Irrespective of what the package maintainers of each package assert the dependencies, we can generate a ‘reduced-package.tgz’ that contains the required assertion by eliminating the redundant ones. I will contact the debian packagers soon.

Martin, we are very soon going to harvest all of debian, from the start till date, and will include all categories of each release. This will be available permanently.

Nagarjuna

By: Marcin Owsiany

Marcin Owsiany — Sun, 18 Jan 2009 17:23:10 +0000

I’m interested in obtaining the graphs for some packages from the “experimental” distribution. Can you make available the software used to transform the Packages files into the input files for plotting?

By: John Ellson

John Ellson — Sun, 11 Jan 2009 16:26:25 +0000

Gnowgi said:
> Can you consider writing an algorithm for cleaning the redundantly asserted dependencies?

There is a tool called “tred” from the graphviz package which can be used to do this “transitive reduction” of a graph.

John

By: gnowgi

gnowgi — Sun, 11 Jan 2009 13:30:38 +0000

Thanks for your information. We are not aware of your paper. We did a non-linear fit to the data. Please check the abstract version at http://www.gnowledge.org/scalefree. A full version will appear shortly. We will cite your work. Thanks again.

Nagarjuna