A while ago I wrote about the new distcheck tool upcoming in dose3. I’ve recently updated the proposal on the debian wiki to reflect recent changes in the yaml data structure. The idea was to remove redundant information, to make it easier to read and at the same time include enough details to make it easy to use from a script. I’ll write down a small example to explain the format. A package can be broken because of a missing package or because of a conflict. For a missing package we’ll have a stanza like this :
package: libgnuradio-dev
version: 3.2.2.dfsg-1
architecture: all
source: gnuradio (= 3.2.2.dfsg-1)
status: broken
reasons:
-
missing:
pkg:
package: libgruel0
version: 3.2.2.dfsg-1+b1
architecture: amd64
missingdep: libboost-thread1.40.0 (>= 1.40.0-1)
paths:
-
depchain:
-
package: libgnuradio-dev
version: 3.2.2.dfsg-1
architecture: all
depends: libgnuradio (= 3.2.2.dfsg-1)
-
package: libgnuradio
version: 3.2.2.dfsg-1
architecture: all
depends: libgnuradio-core0
-
package: libgnuradio-core0
version: 3.2.2.dfsg-1+b1
architecture: amd64
depends: libgruel0 (= 3.2.2.dfsg-1+b1)
The first part gives details about the package libgnuradio-dev, specifying its status, source and architecture. The second part is the reason of the problem. In this case it is a missing package that is essential to install libgnuradio-dev. missindep is the dependency that cannot be satisfied is the package libgruel0 , in this case: libboost-thread1.40.0 (>= 1.40.0-1).
The paths component gives all possible depchains from the root package libgnuradio-dev to libgruel0 . Notice that we do not include the last node in the dependency chain to avoid a useless repetition. Of course there might be more then on path to reach libgruel0. Distcheck will unroll all of them. Because of the structure of debian dependencies usually there are not so many paths.
The other possible cause of a problem is a conflict. Consider the following :
package: a
version: 1
status: broken
reasons:
-
conflict:
pkg1:
package: e
version: 1
pkg2:
package: f
version: 1
depchain1:
-
depchain:
-
package: a
version: 1
depends: b
-
package: b
version: 1
depends: e
depchain2:
-
depchain:
-
package: a
version: 1
depends: d
-
package: d
version: 1
depends: f
This is the general case of a deep conflict. I use an artificial example here instead of a concrete one since this case is not very common and I was not able to find one. To put everything in context, this is the example I’ve used (it’s in cudf format, but I think you get the gist of it):
package: a
version: 1
depends: b, d
package: b
version: 1
depends: e
package: d
version: 1
depends: f
package: f
version: 1
conflicts: e
package: e
version: 1
conflicts: f
The first part of the distcheck report is as before with details about the broken package. Since this is a conflict, and all conflicts are binary, we give the two packages involved in the conflict first. Packages f and e are in conflict, but they are not direct dependency of package a . For this reason, we output the two paths that from a lead to f or e. All dependency chains for each conflict are together. Again, since there might be more than one way from a to reach the conflicting packages, we can have more then one depchain.
Another important upcoming change is distcheck (to be implemented soon) it the ability to check if a package is in conflict with an Essential package. In the past edos-debcheck always check the installability of a package in the empty universe. This assumption is actually not true for debian as all essential packages should always be installed. For this reason, now distcheck will check the installability problem not in an empty universe, but in a universe with all essential packages installed.
This check is not going to be fool proof though. Because of the semantic of essential packages, despite is not possible to remove a package toutcourt, an essential package can be replaced by a non essential package via the replace mechanism. For example, poking with this feature I noticed that the package upstart in sid replace sysinit and it is in conflict with it. This is perfectly fine as it gives a mechanism to upgrade and replace essential components of the system. At the same time this does not fit in the edos-debcheck philosophy of checking packages for installation problems in the empty universe (or in a universe with all essential packages installed). At the moment we are still thinking how to address this problem (the solution will be in the long term to add the replace semantic in distcheck), but for the moment we will just provide an option to check packages w.r.t essential packages conscious the this can lead to false positives.
This work is of course done in collaboration with the mancoosi team in paris.
Dose3 is still not ready for prime time. We are preparing debian packages and we plan to upload them in experimental in the near feature.