Dose-Debcheck: Not Installable Packages
Results of the different checks
These checks are run daily on qa.debian.org:- Unstable:
- main
- contrib + non-free (with main as background)
- main build dependencies
- main cross build dependencies on amd64
- Testing:
- main
- contrib + non-free (with main as background)
- main build dependencies
What it means
We call a package installable if all its (recursive) dependencies can be satisfied without violating any conflicts. More precisely, a package p is called installable in a package repository D if there is a subset S of D containing p, and such that for each package in S
- every dependency relation is satisfied by some package in S
- and it is not in conflict with any package in S
In case a package exists with multiple versions in a distribution (which may happen in the unstable distribution), only the latest version is checked for installability.
How it is done
The set of not installable packages is computed using the dose-debcheck tool available in the dose-distcheck package, the successor of the previously used edos-debcheck tool.
Filing bugs
Whether a not-installable package deserves a bug report depends on the situation:- All packages in the stable and testing
distribution should be installable, with the exception of packages
with Architecture=all. The reason for the latter
exception is that these packages are usually available for each
architecture, regardless of the fact whether their dependencies
can be satisfied on that architecture or not. However, when a
package with Architecture=all is not installable on any
architecture then something is wrong.
Normally, a bug should be filed only when a package is not installable on any architecture (regardless of the value of the Architecture field of the package). In any case, the situation should be investigated before filing a bug. For instance, it may be the case that a package is installable only in a multi-arch setting.
- By its very nature, the unstable distribution is expected to
have many packages that are not installable. However, this should normally
be temporary. That means that, in addition to the above restrictions:
- Bugs should be filed only when the problem exists over an extended period of time (say, 1 month).
- Bugs should not be filed when a package is involved in a transition as these cases are already monitored.