Home My Page Projects Dose: library and tools
Summary Activity Tracker Lists SCM Files

[#20873] Strong dependency graph includes *all* Essential:yes packages

2016-10-12 08:12
Submitted by:
Johannes Schauer (josch)
Assigned to:
Nobody (None)
Strong dependency graph includes *all* Essential:yes packages

Detailed description
Consider the following Packages file:

Package: bar
Version: 1
Architecture: amd64

Package: foo
Version: 1
Essential: yes
Architecture: amd64

Package: foo
Version: 2
Essential: yes
Architecture: amd64

Now generate a strong dependency graph:

./ceve.native -G strdeps -T dot --deb-native-arch=amd64 deb://Packages
digraph G {
"foo:amd64 (= 2)";
"foo:amd64 (= 1)";
"bar:amd64 (= 1)";

"foo:amd64 (= 2)" -> "foo:amd64 (= 1)";
"foo:amd64 (= 1)" -> "foo:amd64 (= 2)";
"bar:amd64 (= 1)" -> "foo:amd64 (= 1)";
"bar:amd64 (= 1)" -> "foo:amd64 (= 2)";


As one can see, "bar" strongly depends on "foo" in versions "1" *and* "2". But these two are not even co-installable. This effect occurs because all cudf packages with the property "essential" set to "true" are added as direct successors of vertices in the package graph. So the current behaviour is certainly wrong and undesirable. The question is what the right solution is.

As per definition of strong dependencies, probably the most *correct* solution would be to neither add the package "foo" in version "1" nor in version "2" to the strong dependency set because there exist installation sets for "bar" without either of them.

I propose a simple fix: find all Essential:yes Debian packages which are installable and group their cudf representation together by package name. Thus, we end up with multiple groups where each group contains installable packages of the same name but potentially different version and architecture. Then, only add those cudf packages to the strong dependency set where the group that was created for them in this manner is of cardinality one. This means that Essential:yes packages that exist in multiple versions or for multiple architectures are not considered to be part of the strong dependency set.

Does this sound reasonable?

Another question is, how reasonable or expected it is to generate a strong installation set that does not potentially include "some" Essential:yes packages which happen to appear in multiple versions or architectures?

No Comments Have Been Posted

No Changes Have Been Made to This Item