[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

announcing edos.debian.net



Hello,

I am happy to announce the availability of daily runs of
edos-debcheck. The results can be accessed here:

    http://edos.debian.net/edos-debcheck/

A first version was set up during the QA meeting in Extremadura, but I
came only recently around to implement some missing features. Fabio
Mancinelli from the EDOS project had helped with the first version.

* edos-debcheck: This tool checks installability of packages inside a
given distribution.  That is, it checks whether there exists a subset of
the distribution containing a given package, and such hat all
dependencies and conflicts of the subset are satisfied. An important
point is that "deep" dependency and conflict chains are tested
correctly. For instance, if you have

A depends on B1, B2
B1 depends on C1
B2 depends on C2
C1 depends on E1
C2 depends on E2
E1 conflicts with E2

then A would be recognized as not installable. Disjunctive
dependencies are handeled correctly, also in conjunction with "deep"
dependencies and conlicts.  This tool is also available in debian in
the package of the same name.

* The results shown on the web page: For each distribution in the
configuration, for each of its architectures, and for a given date two
numbers are given : "n (m)", where

- n is the number of non-installable packages
- m is the number of non-installable packages having their architecture
  set to some specific architecture (that is, different from "all").

Clicking on the numbers gives a detailed list, with explanations why
the packages are not installable. In these lists, packages with
architecture=all are indicated on grey background. There are summary
columns showing packages that are not installable in some or in every
achitecture of a distribution, and diffs between successive runs.

* The special case of architecture=all: The reason why
architecture=all packages are singled out is that there usually is a
good technical excuse why they are not installable. For example, one might
have packages

  Package A
  Architectures: a, b, c

  Package A-common
  Architecture: all
  Depends: A

In this case A-common is not installable on architectures different
from a, b, c, but it wouldn't make much sense to specify this in the
architecture field of A-common.

* Addition of more distros/architectures: If you want more distros or
architectures added to this service please drop me a note.

* Thanks a lot: to the ftbfs.de team, in particular to Martin Zobel-Helas,
for hosting us and for their help.



Reply to: