/usr/share/doc/dose-distcheck/debcheck-primer.html

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="generator" content="hevea 2.09">
<style type="text/css">
.li-itemize{margin:1ex 0ex;}
.li-enumerate{margin:1ex 0ex;}
.dd-description{margin:0ex 0ex 1ex 4ex;}
.dt-description{margin:0ex;}
.toc{list-style:none;}
.footnotetext{margin:0ex; padding:0ex;}
div.footnotetext P{margin:0px; text-indent:1em;}
.thefootnotes{text-align:left;margin:0ex;}
.dt-thefootnotes{margin:0em;}
.dd-thefootnotes{margin:0em 0em 0em 2em;}
.footnoterule{margin:1em auto 1em 0px;width:50%;}
.caption{padding-left:2ex; padding-right:2ex; margin-left:auto; margin-right:auto}
.title{margin:2ex auto;text-align:center}
.titlemain{margin:1ex 2ex 2ex 1ex;}
.titlerest{margin:0ex 2ex;}
.center{text-align:center;margin-left:auto;margin-right:auto;}
.flushleft{text-align:left;margin-left:0ex;margin-right:auto;}
.flushright{text-align:right;margin-left:auto;margin-right:0ex;}
div table{margin-left:inherit;margin-right:inherit;margin-bottom:2px;margin-top:2px}
td table{margin:auto;}
table{border-collapse:collapse;}
td{padding:0;}
.cellpadding0 tr td{padding:0;}
.cellpadding1 tr td{padding:1px;}
pre{text-align:left;margin-left:0ex;margin-right:auto;}
blockquote{margin-left:4ex;margin-right:4ex;text-align:left;}
td p{margin:0px;}
.boxed{border:1px solid black}
.textboxed{border:1px solid black}
.vbar{border:none;width:2px;background-color:black;}
.hbar{border:none;height:2px;width:100%;background-color:black;}
.hfill{border:none;height:1px;width:200%;background-color:black;}
.vdisplay{border-collapse:separate;border-spacing:2px;width:auto; empty-cells:show; border:2px solid red;}
.vdcell{white-space:nowrap;padding:0px; border:2px solid green;}
.display{border-collapse:separate;border-spacing:2px;width:auto; border:none;}
.dcell{white-space:nowrap;padding:0px; border:none;}
.dcenter{margin:0ex auto;}
.vdcenter{border:solid #FF8000 2px; margin:0ex auto;}
.minipage{text-align:left; margin-left:0em; margin-right:auto;}
.marginpar{border:solid thin black; width:20%; text-align:left;}
.marginparleft{float:left; margin-left:0ex; margin-right:1ex;}
.marginparright{float:right; margin-left:1ex; margin-right:0ex;}
.theorem{text-align:left;margin:1ex auto 1ex 0ex;}
.part{margin:2ex auto;text-align:center}
.example{border:solid black;background:#eeddbb;padding:lex}
</style>
<title>The Dose-Debcheck Primer
</title>
</head>
<body >
<!--HEVEA command line is: /usr/bin/hevea -exec xxdate.exe -fix debcheck-primer.tex -->
<!--CUT STYLE article--><!--CUT DEF section 1 --><table class="title"><tr><td style="padding:1ex"><h1 class="titlemain">The Dose-Debcheck Primer</h1><h3 class="titlerest">Pietro Abate, Roberto Di Cosmo, Ralf Treinen, Stefano Zacchiroli</h3><h3 class="titlerest">December
 23, 2013</h3></td></tr>
</table><p>The dose-debcheck tool determines, for a set of package control stanzas,
called <em>the repository</em>, whether packages of the repository can
be installed relative to the repository. Typically, the repository is
a <span style="font-family:monospace">Packages</span> file of a Debian suite. The installability check
is by default performed for all package stanzas in the repository, but
may be also be restricted to a subset of these.</p><p>This primer applies to version 3.1.3 of dose-debcheck. </p><!--TOC section id="sec1" Contents-->
<h2 id="sec1" class="section">Contents</h2><!--SEC END --><ul class="toc"><li class="li-toc">
<a href="#sec2">1  Input Data: Packages and Repositories</a>
<ul class="toc"><li class="li-toc">
<a href="#sec3">1.1  Packages</a>
</li><li class="li-toc"><a href="#sec4">1.2  Repositories</a>
</li></ul>
</li><li class="li-toc"><a href="#sec5">2  Installability</a>
<ul class="toc"><li class="li-toc">
<a href="#sec6">2.1  A Precise Definition</a>
</li><li class="li-toc"><a href="#sec7">2.2  What Installability does Not Mean</a>
</li><li class="li-toc"><a href="#sec8">2.3  Co-installability</a>
</li></ul>
</li><li class="li-toc"><a href="#sec9">3  Invocation</a>
<ul class="toc"><li class="li-toc">
<a href="#sec10">3.1  Basic usage</a>
</li><li class="li-toc"><a href="#sec11">3.2  Checking only selected packages</a>
</li><li class="li-toc"><a href="#sec12">3.3  Checking for co-installability</a>
</li><li class="li-toc"><a href="#sec13">3.4  Changing the Notion of Installability</a>
</li><li class="li-toc"><a href="#sec14">3.5  Filtering Packages and Multiarch</a>
</li><li class="li-toc"><a href="#sec15">3.6  Other Options</a>
</li></ul>
</li><li class="li-toc"><a href="#sec16">4  Output</a>
<ul class="toc"><li class="li-toc">
<a href="#sec17">4.1  Understanding Explanations of Installability</a>
</li><li class="li-toc"><a href="#sec18">4.2  Understanding Explanations of Non-installability</a>
<ul class="toc"><li class="li-toc">
<a href="#sec19">4.2.1  Explanation in Case of a Missing Package</a>
</li><li class="li-toc"><a href="#sec20">4.2.2  Explanation in Case of a Conflict</a>
</li></ul>
</li><li class="li-toc"><a href="#sec21">4.3  The output in case of co-installability queries</a>
</li></ul>
</li><li class="li-toc"><a href="#sec22">5  Exit codes</a>
</li><li class="li-toc"><a href="#sec23">6  Tips and Tricks</a>
<ul class="toc"><li class="li-toc">
<a href="#sec24">6.1  Encoding checks involving several packages</a>
</li><li class="li-toc"><a href="#sec25">6.2  Parsing dose-debcheck’s output in Python</a>
</li><li class="li-toc"><a href="#sec26">6.3  Usage as a test in a shell script</a>
</li></ul>
</li><li class="li-toc"><a href="#sec27">7  Credits</a>
</li><li class="li-toc"><a href="#sec28">8  Further Reading</a>
</li><li class="li-toc"><a href="#sec29">9  Copyright and Licence</a>
</li></ul>
<!--TOC section id="sec2" Input Data: Packages and Repositories-->
<h2 id="sec2" class="section">1  Input Data: Packages and Repositories</h2><!--SEC END --><p>
<a id="sec:data"></a>
</p>
<!--TOC subsection id="sec3" Packages-->
<h3 id="sec3" class="subsection">1.1  Packages</h3><!--SEC END --><p>
<a id="sec:packages"></a>
Debian control stanzas are defined in <span style="font-family:monospace">deb-control (5)</span>. For
dose-debcheck only the following fields are relevant, all others are
ignored:
</p><dl class="description"><dt class="dt-description">
<span style="font-weight:bold">Package</span></dt><dd class="dd-description"> giving the package name. dose-debcheck is more liberal as
to which package names are acceptable, for instance it allows a
slightly larger character set than the debian policy for
constituting names. Required.
</dd><dt class="dt-description"><span style="font-weight:bold">Version</span></dt><dd class="dd-description"> giving the version of the package. The version must be
in conformance with the Debian policy. Required.
</dd><dt class="dt-description"><span style="font-weight:bold">Architecture</span></dt><dd class="dd-description"> specifying the architectures on which the package
may be installed. Required.
</dd><dt class="dt-description"><span style="font-weight:bold">Multiarch</span></dt><dd class="dd-description"> specifies whether the package may be installed
simultaneously for different architectures, and whether it may
satisfy dependencies across architecture boundaries. Values may be
<span style="font-family:monospace">No</span>, <span style="font-family:monospace">Same</span>, <span style="font-family:monospace">Foreign</span>, or <span style="font-family:monospace">Allowed</span>
([<a href="#ubuntu%3Amultiarch">Lan11</a>]). Optional, defaults to <span style="font-family:monospace">No</span>.
</dd><dt class="dt-description"><span style="font-weight:bold">Depends</span></dt><dd class="dd-description"> is a list of items required for the installation of
this package. Each item is a package name optionally with a version
constraint, or a disjunction of these. Items may also be annotated
with <span style="font-family:monospace">:any</span>. Optional, defaults to the empty list.
</dd><dt class="dt-description"><span style="font-weight:bold">Pre-Depends</span></dt><dd class="dd-description"> are by dose-debcheck treated like Depends.
</dd><dt class="dt-description"><span style="font-weight:bold">Conflicts</span></dt><dd class="dd-description"> is a list of package names, possibly with a version
constraint, that cannot be installed together with the package. Optional,
defaults to the empty list.
</dd><dt class="dt-description"><span style="font-weight:bold">Breaks</span></dt><dd class="dd-description"> are by dose-debcheck treated like Conflicts.
</dd><dt class="dt-description"><span style="font-weight:bold">Provides</span></dt><dd class="dd-description"> is a list of names symbolizing functionalities
realized by the package. They have to be taken into account for
dependencies and conflicts of other packages, see
Section <a href="#sec%3Ainstallability">2</a>. Optional, defaults to the empty
list.
</dd><dt class="dt-description"><span style="font-weight:bold">Essential</span></dt><dd class="dd-description"> specifies whether the package must be installed
(<span style="font-family:monospace">yes</span> or <span style="font-family:monospace">no</span>). Optional, defaults to <span style="font-family:monospace">no</span>.
</dd></dl><p>In particular, <span style="font-family:monospace">Recommends</span> and <span style="font-family:monospace">Suggests</span> are ignored
by dose-debcheck. Also, dose-debcheck does not check for the presence of
fields that are required by Debian policy but that are not relevant
for the task of dose-debcheck, like <span style="font-family:monospace">Maintainer</span> or
<span style="font-family:monospace">Description</span>.</p><p>Also note that dose-debcheck is slightly more liberal than the Debian
policy in accepting input, and hence cannot be used to check strict
policy conformance of package stanzas.</p>
<!--TOC subsection id="sec4" Repositories-->
<h3 id="sec4" class="subsection">1.2  Repositories</h3><!--SEC END --><p>
<a id="sec:repositories"></a>
A <em>repository</em> is a set of package stanzas. This set may be given
to dose-debcheck in form of a single file or as several files, in the
latter case the repository is constituted by all stanzas in all input
files (see Section <a href="#sec%3Ainvocation">3</a>). dose-debcheck assures that the
repositories has two important properties:</p><ol class="enumerate" type=1><li class="li-enumerate">
We assume that there are no two package stanzas in the repository
that have the same values of all three fields <span style="font-family:monospace">Package</span>,
<span style="font-family:monospace">Version</span>, and <span style="font-family:monospace">Architecture</span>. Having different
versions for the same package name is OK, as it is of course OK to
have two stanzas with different package names and the same version.
In other words, the dose-debcheck tool uses internally the triple of
name, architecture and version as an identifier for packages.<p>In the following, when we speak of <em>a package</em>, we mean a
precise package stanza that is identified by a name, a version, and
an architecture, like the package of name <span style="font-family:monospace">gcc</span> in version
<span style="font-family:monospace">4:4.3.2-2</span> and for architecture <span style="font-family:monospace">amd64</span>. The stanza with name
<span style="font-family:monospace">gcc</span> and version <span style="font-family:monospace">4:4.4.4-2</span> for architecture
<span style="font-family:monospace">amd64</span> would constitute a different package.</p><p>If the input contains several stanzas with the same name, version
and architecture then all but the last such stanza are dropped, and a 
warning message is issued.</p><div class="example"><p><span style="font-weight:bold">Example:</span> The following input does not constitute a repository:
</p><pre class="verbatim">Package: abc
Version: 42
Architecture: amd64
Depends: xyz

Package: abc
Version: 42
Architecture: amd64
Depends: pqr
</pre><p>The reason is that the triple (<span style="font-style:italic">abc</span>,42,<span style="font-style:italic">amd</span>64) is not
unique. dose-debcheck will warn us that it only accepts the second
stanza and drops the first one from its input:
</p><pre class="verbatim">(W)Debian: the input contains two packages with the same name, version and architecture (abc,42,amd64). Only the latter will be considered.
</pre></div></li><li class="li-enumerate">We assume that Multiarch information is consistent: If the
repository contains packages with the same name and version and
different architecture then both packages have to agree on the value
of their <span style="font-family:monospace">Multiarch</span> field.</li></ol>
<!--TOC section id="sec5" Installability-->
<h2 id="sec5" class="section">2  Installability</h2><!--SEC END --><p>
<a id="sec:installability"></a></p>
<!--TOC subsection id="sec6" A Precise Definition-->
<h3 id="sec6" class="subsection">2.1  A Precise Definition</h3><!--SEC END --><p>In order to understand what installability exactly means for us we
need a little bit of theory. Let <span style="font-style:italic">R</span> be a repository (see
Section <a href="#sec%3Adata">1</a>). An <span style="font-style:italic">R</span><em>-installation set</em>, or sometimes
simply called an <span style="font-style:italic">R</span><em>-installation</em>, is a subset <span style="font-style:italic">I</span> of <span style="font-style:italic">R</span> that
has the following four properties:
</p><dl class="description"><dt class="dt-description">
<span style="font-weight:bold">flatness:</span></dt><dd class="dd-description"> <span style="font-style:italic">I</span> does not contain two different packages with
the same name (which then would have different versions or
architecture), unless the package is marked as
<span style="font-family:monospace">Multiarch=Same</span>. If package (<span style="font-style:italic">p</span>,<span style="font-style:italic">a</span>,<span style="font-style:italic">n</span>) has
<span style="font-family:monospace">Multiarch=Same</span> then <span style="font-style:italic">I</span> just must not contain any package
with name <span style="font-style:italic">p</span> and a version different from <span style="font-style:italic">n</span>.
</dd><dt class="dt-description"><span style="font-weight:bold">abundance:</span></dt><dd class="dd-description"> For each package <span style="font-style:italic">p</span> in <span style="font-style:italic">I</span>, every of its
dependencies is satisfied by some package <span style="font-style:italic">q</span> in <span style="font-style:italic">I</span>, either
directly or through a virtual package in case the dependency does
not carry a version constraint. 
<ul class="itemize"><li class="li-itemize">
If <span style="font-style:italic">q</span> has a Multiarch value of <span style="font-family:monospace">No</span> or <span style="font-family:monospace">Same</span>
then the architecture of <span style="font-style:italic">q</span> must be the same as the
architecture of <span style="font-style:italic">p</span>.
</li><li class="li-itemize">If <span style="font-style:italic">q</span> has a Multiarch value of <span style="font-family:monospace">Foreign</span> then the
architecture of <span style="font-style:italic">q</span> may be different then the architecture of <span style="font-style:italic">p</span>.
</li><li class="li-itemize">If <span style="font-style:italic">q</span> has a Multiarch value of <span style="font-family:monospace">Allowed</span> then the
architecture of <span style="font-style:italic">q</span> must be the same as the architecture of <span style="font-style:italic">p</span>,
or the dependency relation must carry the annotation <span style="font-family:monospace">:any</span>.
</li></ul>
In this context, the architecture value <span style="font-family:monospace">all</span> is identified with
the native architecture [<a href="#ubuntu%3Amultiarch">Lan11</a>].
</dd><dt class="dt-description"><span style="font-weight:bold">peace:</span></dt><dd class="dd-description"> For each package in <span style="font-style:italic">I</span> and for each item in its list
of conflicts, no package in <span style="font-style:italic">I</span> satisfies the description of that
item. As an exception, it is allowed that a package in <span style="font-style:italic">I</span> both
provides a virtual package and at the same time conflicts with it.
</dd><dt class="dt-description"><span style="font-weight:bold">foundation:</span></dt><dd class="dd-description"> If package (<span style="font-style:italic">p</span>,<span style="font-style:italic">n</span>)∈ <span style="font-style:italic">R</span> is essential, then <span style="font-style:italic">I</span>
must contain a package (<span style="font-style:italic">p</span>,<span style="font-style:italic">m</span>) such that (<span style="font-style:italic">p</span>,<span style="font-style:italic">m</span>) is essential.
</dd></dl><p>
Hence, the notion of an installation captures the idea that a certain
set of packages may be installed together on a machine, following the
semantics of binary package relations according to the Debian Policy.
The foundation requirement expresses that essential packages must be
installed; it is formulated in a way that also caters to the
(extremely rare) case that a package changes its <span style="font-family:monospace">Essential</span>
value between different versions. The foundation property may be
switched off by giving the option <span style="font-family:monospace">--deb-ignore-essential</span>.</p><div class="example"><p><span style="font-weight:bold">Example:</span>
Let <span style="font-style:italic">R</span> be the following repository:
</p><pre class="verbatim">    Package: a
    Version: 1
    Depends: b (&gt;= 2) | v

    Package: a 
    Version: 2
    Depends: c (&gt; 1)

    Package: b
    Version: 1
    Conflicts: d

    Package: c
    Version: 3
    Depends: d
    Conflicts: v

    Package: d
    Version: 5
    Provides: v
    Conflicts: v
</pre><p>The following subsets of <span style="font-style:italic">R</span> are not <span style="font-style:italic">R</span>-installation sets:
</p><ul class="itemize"><li class="li-itemize">
The complete set <span style="font-style:italic">R</span> since it is not flat (it contains two
different packages with name <span style="font-style:italic">a</span>)
</li><li class="li-itemize">The set {(<span style="font-style:italic">a</span>,1), (<span style="font-style:italic">c</span>,3)} since it not abundant (the dependency
of (<span style="font-style:italic">a</span>,1) is not satisfied, nor is the dependency of (<span style="font-style:italic">c</span>,3)).
</li><li class="li-itemize">The set {(<span style="font-style:italic">a</span>,2), (<span style="font-style:italic">c</span>,3), (<span style="font-style:italic">d</span>,5)} since it is not in peace
(there is conflict between (<span style="font-style:italic">c</span>,3) and (<span style="font-style:italic">d</span>,5) via the virtual package <span style="font-style:italic">v</span>)
</li></ul><p>
Examples of <span style="font-style:italic">R</span>-installation sets are
</p><ul class="itemize"><li class="li-itemize">
The set {(<span style="font-style:italic">d</span>,5)} (self conflicts via virtual packages are ignored)
</li><li class="li-itemize">The set {(<span style="font-style:italic">a</span>,1), (<span style="font-style:italic">b</span>,1)}
</li><li class="li-itemize">The set {(<span style="font-style:italic">a</span>,1), (<span style="font-style:italic">d</span>,5)}
</li></ul></div><p>A package (<span style="font-style:italic">p</span>,<span style="font-style:italic">n</span>) is said to be <em>installable</em> in a repository <span style="font-style:italic">R</span>
if there exists an <span style="font-style:italic">R</span>-installation set <span style="font-style:italic">I</span> that contains (<span style="font-style:italic">p</span>,<span style="font-style:italic">n</span>).</p><div class="example"><p><span style="font-weight:bold">Example:</span>
In the above example, (<span style="font-style:italic">a</span>,1) is <span style="font-style:italic">R</span>-installable since it is contained
in the <span style="font-style:italic">R</span>-installation set {(<span style="font-style:italic">a</span>,1), (<span style="font-style:italic">d</span>,5) }.</p><p>However, (<span style="font-style:italic">a</span>,2) is not <span style="font-style:italic">R</span>-installable: Any <span style="font-style:italic">R</span>-installation set
containing (<span style="font-style:italic">a</span>,2) must also contain (<span style="font-style:italic">c</span>,3) (since it is the only
package in <span style="font-style:italic">R</span> that can satisfy the dependency of (<span style="font-style:italic">a</span>,2) on <span style="font-style:italic">c</span>
(&gt;1), and in the same way it must also contain (<span style="font-style:italic">d</span>,5). However, this
destroys the peace as (<span style="font-style:italic">c</span>,3) and (<span style="font-style:italic">d</span>,5) are in conflict. Hence, no such
<span style="font-style:italic">R</span>-installation set can exist.
</p></div>
<!--TOC subsection id="sec7" What Installability does Not Mean-->
<h3 id="sec7" class="subsection">2.2  What Installability does Not Mean</h3><!--SEC END --><ul class="itemize"><li class="li-itemize">
Installability in the sense of dose-debcheck only concerns the
relations between different binary packages expressed in their
respective control files. It does not mean that a package indeed
installs cleanly in a particular environment since an installation
attempt may still fail for different reasons, like failure of a
maintainer script or attempting to hijack a file owned by another
already installed package.
</li><li class="li-itemize">Installability means theoretical existence of a solution. It
does not mean that a package manager (like <span style="font-family:monospace">aptitude</span>,
<span style="font-family:monospace">apt-get</span>) actually finds a way to install that package.
This failure to find a solution may be due to an inherent
incompleteness of the dependency resolution algorithm employed by
the package manager, or may be due to user-defined preferences that
exclude certain solutions.
</li></ul>
<!--TOC subsection id="sec8" Co-installability-->
<h3 id="sec8" class="subsection">2.3  Co-installability</h3><!--SEC END --><p>
<a id="sec:coinstallability"></a>
One also should keep in mind that, even when two packages are
<span style="font-style:italic">R</span>-installable, this does not necessarily mean that both packages can
be installed <em>together</em>. A set <span style="font-style:italic">P</span> of packages is called
<span style="font-style:italic">R</span>-<em>co-installable</em> when there exists a single <span style="font-style:italic">R</span>-installation
set extending <span style="font-style:italic">P</span>.</p><div class="example"><p><span style="font-weight:bold">Example:</span>
Again in the above example, both (<span style="font-style:italic">b</span>,1) and (<span style="font-style:italic">d</span>,5) are
<span style="font-style:italic">R</span>-installable; however they are not <span style="font-style:italic">R</span>-co-installable.
</p></div><p>See Section <a href="#sec%3Atricks">6</a> on how co-installability can be encoded.

</p>
<!--TOC section id="sec9" Invocation-->
<h2 id="sec9" class="section">3  Invocation</h2><!--SEC END --><p>
<a id="sec:invocation"></a></p>
<!--TOC subsection id="sec10" Basic usage-->
<h3 id="sec10" class="subsection">3.1  Basic usage</h3><!--SEC END --><p>dose-debcheck accepts several different options, and also arguments.</p><pre>
  dose-debcheck [option] ... [file] ...
</pre><p>The package repository is partionend into a <em>background</em> and a
<em>foreground</em>. The foreground contains the packages we are actually
interested in, the background contains packages that are just available
for satisfying dependencies, but for which we do not care about installability.</p><p>All arguments are interpreted as filenames of Packages input files,
the contents of which go into the foreground. If no argument is given
then metadata of foreground packages is read from standard input. In
addition, one may specify listings of foreground packages with the
option <code>--fg=&lt;filename&gt;</code>, and listings of background packages
with the option <code>--bg=&lt;filename&gt;</code>. Input from files (but not from
standard input) may be compressed with gzip or bzip2, provided
dose-debcheck was compiled with support for these compression libraries.</p><p>The option <span style="font-family:monospace">-f</span> and <span style="font-family:monospace">-s</span> ask for a listing of uninstallable,
resp. installable packages. The option <span style="font-family:monospace">-e</span> asks for an explanation
of each reported case. The exact effect of these options will be explained
in Section <a href="#sec%3Aoutput">4</a>.</p><div class="example"><p><span style="font-weight:bold">Example:</span>
We may check whether packages in <span style="font-style:italic">non-free</span> are installable,
where dependencies may be satisfied from <span style="font-style:italic">main</span> or <span style="font-style:italic">contrib</span>:
</p><pre class="verbatim">dose-distcheck  -f -e \
    --bg=/var/lib/apt/lists/ftp.fr.debian.org_debian_dists_sid_main_binary-amd64_Packages\
    --bg=/var/lib/apt/lists/ftp.fr.debian.org_debian_dists_sid_contrib_binary-amd64_Packages\
    /var/lib/apt/lists/ftp.fr.debian.org_debian_dists_sid_non-free_binary-amd64_Packages
</pre></div>
<!--TOC subsection id="sec11" Checking only selected packages-->
<h3 id="sec11" class="subsection">3.2  Checking only selected packages</h3><!--SEC END --><p>
<a id="sec:invocation-background"></a>
The initial distinction between foreground and background packages is
modified when using the <code>--checkonly</code> option. This option takes
as value a comma-separated list of package names, possibly qualified
with a version constraint. The effect is that only packages that match
one of these package names are kept in the foreground, all others are
pushed into the background.</p><div class="example"><p><span style="font-weight:bold">Example:</span>
</p><pre>
dose-debcheck --checkonly "libc6, 2ping (= 1.2.3-1)" Packages
</pre></div>
<!--TOC subsection id="sec12" Checking for co-installability-->
<h3 id="sec12" class="subsection">3.3  Checking for co-installability</h3><!--SEC END --><p>
<a id="sec:invocation-coinst"></a>
Co-installability of packages can be easily checked with the
<code>--coinst</code> option. This option takes as argument a
comma-separated list of packages, each of them possibly with a version
constraint. In that case, dose-debcheck will check whether the packages
specified are co-installable, that is whether it is possible to
install these packages at the same time (see
Section <a href="#sec%3Acoinstallability">2.3</a>).</p><p>Note that it is possible that the name of a package, even when
qualified with a version constraint, might be matched by several
packages with different versions. In that case, co-installability will
be checked for <em>each</em> combination of real packages that match the
packages specified in the argument of the <code>--coinst</code> option.
</p><div class="example"><p><span style="font-weight:bold">Example:</span>
Consider the following repository (architectures are omitted for
clarity):
</p><pre class="verbatim">Package: a
Version: 1

Package: a 
Version: 2

Package: a
Version: 3

Package: b
Version: 10

Package: b
Version: 11

...
</pre><p>Executing the command <code>debcheck --coinst a (&gt;1), b</code> on this
repository will check co-installability of 4 pairs of packages: there
are two packages that match <code>a (&gt;1)</code>, namely package <span style="font-family:monospace">a</span> in
versions 2 and 3, and there are two packages that match <span style="font-family:monospace">b</span>. Hence,
the following four pairs of packages will be checked for co-installability:
</p><ol class="enumerate" type=1><li class="li-enumerate">
(a,2), (b,10)
</li><li class="li-enumerate">(a,2), (b,11)
</li><li class="li-enumerate">(a,3), (b,10)
</li><li class="li-enumerate">(a,3), (b,11)
</li></ol></div><p>Mathematically speaking, the set of checked tuples is the Cartesian product
of the denotations of the single package specifications.</p>
<!--TOC subsection id="sec13" Changing the Notion of Installability-->
<h3 id="sec13" class="subsection">3.4  Changing the Notion of Installability</h3><!--SEC END --><p>Some options affect the notion of installability:
</p><ul class="itemize"><li class="li-itemize">
<span style="font-family:monospace">--deb-ignore-essential</span> drops the Foundation requirement
of installation sets (Section <a href="#sec%3Ainstallability">2</a>). In other
words, it is no longer required that any installation set contains all
essential packages.
</li></ul><p>Other options concern Multiarch:
</p><ul class="itemize"><li class="li-itemize">
<span style="font-family:monospace">--deb-native-arch=</span><span style="font-style:italic">a</span> sets the native
architecture to the value <span style="font-style:italic">a</span>. Note that the native architecture is
not necessarily the architecture on which the tool is executed, it
is just the primary architecture for which we are checking
installability of packages. In particular, packages with the
architecture field set to <span style="font-family:monospace">all</span> are interpreted as packages of the
native architecture [<a href="#ubuntu%3Amultiarch">Lan11</a>].
</li><li class="li-itemize"><span style="font-family:monospace">--deb-foreign-archs=</span><span style="font-style:italic">a</span><sub>1</sub>,…,<span style="font-style:italic">a</span><sub><span style="font-style:italic">n</span></sub> sets the foreign
architectures to the list <span style="font-style:italic">a</span><sub>1</sub>,…,<span style="font-style:italic">a</span><sub><span style="font-style:italic">n</span></sub>. Packages may only be installed
when their architecture is the native architecture (including <span style="font-family:monospace">all</span>),
or one of the foreign architectures.
</li></ul>
<!--TOC subsection id="sec14" Filtering Packages and Multiarch-->
<h3 id="sec14" class="subsection">3.5  Filtering Packages and Multiarch</h3><!--SEC END --><p>
Filtering out packages is a different operation than pushing packages
into the background (Section <a href="#sec%3Ainvocation-background">3.2</a>): Background
packages are still available to satisfy dependencies, while filtering out a 
package makes it completely invisible.</p><ul class="itemize"><li class="li-itemize">
The effect of <span style="font-family:monospace">--latest</span> is to keep only the latest version of any
package.
</li></ul>
<!--TOC subsection id="sec15" Other Options-->
<h3 id="sec15" class="subsection">3.6  Other Options</h3><!--SEC END --><p>
Other options controlling the output are explained in detail in
Section <a href="#sec%3Aoutput">4</a>. A complete listing of all options can be found in
the dose-debcheck(1) manpage.</p>
<!--TOC section id="sec16" Output-->
<h2 id="sec16" class="section">4  Output</h2><!--SEC END --><p>
<a id="sec:output"></a>
The output of dose-debcheck is in the YAML format, see
Section <a href="#sec%3Atricks-python">6.2</a> for how to parse the output.</p><p>Without any particular options, dose-debcheck just reports some
statistics:
</p><div class="example"><p><span style="font-weight:bold">Example:</span>
</p><pre class="verbatim">% dose-debcheck rep1
background-packages: 0
foreground-packages: 4
total-packages: 4
broken-packages: 1
</pre></div><p>With the options <span style="font-family:monospace">--failures</span> and <span style="font-family:monospace">--successes</span>, dose-debcheck
reports findings of the requested kind for all packages in the foreground.
These options may be used alone or in combination. In any case, the status
field tells whether the package is found to be installable (value <span style="font-family:monospace">ok</span>)
or non-installable (value <span style="font-family:monospace">broken</span>).</p><div class="example"><p><span style="font-weight:bold">Example:</span>
</p><pre class="verbatim">% dose-debcheck --failures --successes rep1
report:
 -
  package: a
  version: 1
  architecture: amd64
  source: a (= 1)
  status: broken
  
 -
  package: a
  version: 2
  architecture: amd64
  source: a (= 2)
  status: ok
  
 -
  package: b
  version: 1
  architecture: amd64
  source: b (= 1)
  status: ok
  
 -
  package: c
  version: 3
  architecture: amd64
  source: c (= 3)
  status: ok
  
 
background-packages: 0
foreground-packages: 4
total-packages: 4
broken-packages: 1
</pre></div><p>With an additional <span style="font-family:monospace">--explain</span> option, an explanation is given
with each finding. </p>
<!--TOC subsection id="sec17" Understanding Explanations of Installability-->
<h3 id="sec17" class="subsection">4.1  Understanding Explanations of Installability</h3><!--SEC END --><p>An explanation of installability simply consists of an
installation set in the sense of Section <a href="#sec%3Ainstallability">2</a>
containing the package in question.</p><div class="example"><p><span style="font-weight:bold">Example:</span>
</p><pre class="verbatim">% dose-debcheck --explain --successes rep1
report:
 -
  package: a
  version: 2
  architecture: amd64
  source: a (= 2)
  status: ok
  installationset:
   -
    package: c
    version: 3
    architecture: amd64
   -
    package: a
    version: 2
    architecture: amd64
 -
  package: b
  version: 1
  architecture: amd64
  source: b (= 1)
  status: ok
  installationset:
   -
    package: b
    version: 1
    architecture: amd64
</pre></div><p>An installation set contains all essential packages (see
Section <a href="#sec%3Ainstallability">2</a>), which may blow up the output of
installability. Giving the option <span style="font-family:monospace">--deb-ignore-essential</span> will
avoid this, but will also alter the notion of installability in some
corner cases (for instance, when a package needs a version of an
essential package that is not available in the repository).</p>
<!--TOC subsection id="sec18" Understanding Explanations of Non-installability-->
<h3 id="sec18" class="subsection">4.2  Understanding Explanations of Non-installability</h3><!--SEC END --><p>Installability of a package is much easier to explain than
non-installability. The reason for this is that in the former case we
just have to give one installation that our tool has found, while in
the latter case we have to explain why <em>all</em> possible attempts to
install the package must fail. The first consequence of this
observation is that the explanation in case of non-installability may
consist of several components.</p><div class="example"><p><span style="font-weight:bold">Example:</span>
Consider the following repository consisting of only two packages:
</p><pre class="verbatim">Package: a
Version: 1
Depends: b | c

Package: c
Version: 3
Conflicts: a
</pre><p>To explain why package (<span style="font-family:monospace">a</span>,1) is not installable we have to
say why all possible alternative ways to satisfy its dependency must
fail:
</p><ul class="itemize"><li class="li-itemize">
there is no package <span style="font-family:monospace">b</span> in the repository
</li><li class="li-itemize">the only version of package <span style="font-family:monospace">c</span> in the repository is in
conflict with package (<span style="font-family:monospace">a</span>,1)
</li></ul></div><p>There may be several ways to satisfy dependencies due to alternatives
in the dependencies in packages. Alternatives may occur in dependencies
in different forms:
</p><ul class="itemize"><li class="li-itemize">
explicitly, like in <span style="font-family:monospace">Depends: b|c</span>,
</li><li class="li-itemize">through dependency on a package that exists in several versions,
</li><li class="li-itemize">through dependency on a virtual package which is provided by several
(possibly versions of) real packages.
</li></ul><p>
There is one component in the explanation for every possible way to
choose among these alternatives in the dependencies.</p><p>There are only two possible reasons why an attempt to satisfy dependencies
may fail:
</p><ol class="enumerate" type=1><li class="li-enumerate">
dependency on a package that is missing from the repository,
</li><li class="li-enumerate">dependency on a package that is in conflict with some other package
we depend on (possibly through a chain of dependencies).
</li></ol><p>
Each component of the explanation is either a missing package, or a conflict. </p>
<!--TOC subsubsection id="sec19" Explanation in Case of a Missing Package-->
<h4 id="sec19" class="subsubsection">4.2.1  Explanation in Case of a Missing Package</h4><!--SEC END --><p>
A component of the explanation that corresponds to the case of a
missing package consist of two stanzas:
</p><ul class="itemize"><li class="li-itemize">
a <span style="font-family:monospace">pkg</span> stanza that states the package that cannot satisfy
one of its direct dependencies
</li><li class="li-itemize">a <span style="font-family:monospace">depchains</span> stanza containing the dependency chain that
leads from the package we have found non-installable to the one that
cannot satisfy its direct dependency.
</li></ul><div class="example"><p><span style="font-weight:bold">Example:</span>
An explanation might look like this:
</p><pre class="verbatim">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
      unsat-dependency: libboost-thread1.40.0 (&gt;= 1.40.0-1)
     depchains:
      -
       depchain:
        -
         package: libgnuradio-dev
         version: 3.2.2.dfsg-1
         Architecture: all
         Depends: libgnuradio (= 3.2.2.dfsg-1)
        -
         package: libgnuradio
         ersion: 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)
</pre><p>This tells us that <span style="font-family:monospace">libgnuradio-dev</span> in version 3.2.2.<span style="font-style:italic">dfsg</span>−1
is not installable, due to the fact that package <span style="font-family:monospace">libgruel0</span>
in version 3.2.2.<span style="font-style:italic">dfsg</span>−1+<span style="font-style:italic">b</span>1 has a dependency
<span style="font-family:monospace">libboost-thread1.40.0 (&gt;= 1.40.0-1)</span> that is not matched by
any package in the repository. The dependency chain tells why package
<span style="font-family:monospace">libgnuradio-dev</span> in the given version might want to install
<span style="font-family:monospace">libgruel0</span>.
</p></div><p>The depchains component gives all possible dependency chains (<span style="font-style:italic">depchains</span>, for short) from the root package
(<span style="font-family:monospace">libgnuradio-dev</span> in the above example) to the one where a
direct dependency is not matched by any package (<span style="font-family:monospace">libgruel0</span> in
the example). We do not include the last node in the dependency chain
to avoid a useless repetition.</p><p>In general there may be more then one path to reach a certain package
from a given root package, in that case dose-debcheck will unroll all of
them.
</p><div class="example"><p><span style="font-weight:bold">Example:</span>
In the following repository, package <span style="font-family:monospace">a</span> is not installable since 
the dependency of package <span style="font-family:monospace">d</span> cannot be satisfied:
</p><pre class="verbatim">Package: a
Architecture: amd64
Version: 1
Depends: b|c

Package: b
Architecture: amd64
Version: 1
Depends: d

Package: c
Architecture: amd64
Version: 3
Depends: d

Package: d
Architecture: amd64
Version: 42
Depends: x
</pre><p>There are two different ways how <span style="font-family:monospace">a</span> arrives at a dependency on
<span style="font-family:monospace">d</span>. dose-debcheck reports the problem once, but lists the two paths 
from <span style="font-family:monospace">a</span> to <span style="font-family:monospace">d</span>:
</p><pre class="verbatim">% dose-debcheck -e -f --checkonly a rep1
report:
 -
  package: a
  version: 1
  architecture: amd64
  source: a (= 1)
  status: broken
  reasons:
   -
    missing:
     pkg:
      package: d
      version: 42
      architecture: amd64
      unsat-dependency: x
     depchains:
      -
       depchain:
        -
         package: a
         version: 1
         architecture: amd64
         depends: b | c
        -
         package: b
         version: 1
         architecture: amd64
         depends: d
      -
       depchain:
        -
         package: a
         version: 1
         architecture: amd64
         depends: b | c
        -
         package: c
         version: 3
         architecture: amd64
         depends: d
</pre></div>
<!--TOC subsubsection id="sec20" Explanation in Case of a Conflict-->
<h4 id="sec20" class="subsubsection">4.2.2  Explanation in Case of a Conflict</h4><!--SEC END --><p>
The other possible cause of a problem is a conflict. In that case, the
explanation consists of a <span style="font-family:monospace">conflict</span> stanza giving the two
packages that are in direct conflict with each other. Next, we have
two <span style="font-family:monospace">depchain</span> stanzas that lead to the first, resp. the second
of these directly conflicting packages.
</p><div class="example"><p><span style="font-weight:bold">Example:</span>
</p><pre class="verbatim">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
</pre><p>The first part of the dose-debcheck 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 <span style="font-family:monospace">f</span> and <span style="font-family:monospace">e</span> are in conflict, but they
are not direct dependencies of package <span style="font-family:monospace">a</span> . For this reason,
we output the two paths that from a lead to <span style="font-family:monospace">f</span> or
<span style="font-family:monospace">e</span>. 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.
</p></div><p>
If a conflict occurs between two packages that are both reached
through non-trivial dependency chains then we sometimes speak of a
<em>deep conflict</em>.</p>
<!--TOC subsection id="sec21" The output in case of co-installability queries-->
<h3 id="sec21" class="subsection">4.3  The output in case of co-installability queries</h3><!--SEC END --><p>
In case of a co-installability query (with the option
<span style="font-family:monospace">--coinst</span>), the distinction between background and foreground
does no longer make sense since the checks now apply to tuples of packages,
and not to individual packages. As a consequence, the summary looks a bit
different in this case:</p><div class="example"><p><span style="font-weight:bold">Example:</span>
In the following example, there are 3 different versions of package
<span style="font-family:monospace">aa</span>, two different versions of package <span style="font-family:monospace">bb</span> and two
packages with other names, giving rise to 6 pairs of packages to
check for co-installability. Two pairs out of these 6 are found
not co-installable:
</p><pre class="verbatim">% ./debcheck --coinst "aa,bb" coinst.packages 
total-packages: 7
total-tuples: 6
broken-tuples: 2
</pre></div><p>Listings of co-installable, or non co-installable packages when
requested with the options <span style="font-family:monospace">-s</span>/<span style="font-family:monospace">--successes</span>,
resp. <span style="font-family:monospace">-f</span>/<span style="font-family:monospace">--failures</span>, are similar as before but now
start on the word <span style="font-family:monospace">coinst</span> instead of <span style="font-family:monospace">package</span>. Explanations
are as before:</p><div class="example"><p><span style="font-weight:bold">Example:</span>
</p><pre class="verbatim">% ./debcheck --coinst "aa,bb" -s -f -e coinst.simple
report:
 -
  coinst: aa (= 2) , bb (= 11)
  status: ok
  installationset:
   -
    package: aa
    version: 2
    architecture: all
   -
    package: bb
    version: 11
    architecture: all
   -
    package: cc
    version: 31
    architecture: all
 -
  coinst: aa (= 1) , bb (= 11)
  status: broken
  
 reasons:
  -
   conflict:
    pkg1:
     package: aa
     version: 1
     architecture: all
     source: aa (= 1)
     unsat-conflict: cc
    pkg2:
     package: cc
     version: 31
     architecture: all
     source: cc (= 31)
    depchain2:
     
  -
   conflict:
    pkg1:
     package: aa
     version: 1
     architecture: all
     source: aa (= 1)
     unsat-conflict: cc
    pkg2:
     package: cc
     version: 31
     architecture: all
     source: cc (= 31)
    depchain1:
     
    depchain2:
     -
      depchain:
       -
        package: bb
        version: 11
        architecture: all
        depends: cc
  
 
total-packages: 5
total-tuples: 2
broken-tuples: 1
</pre></div>
<!--TOC section id="sec22" Exit codes-->
<h2 id="sec22" class="section">5  Exit codes</h2><!--SEC END --><p>Exit codes 0-63 indicate a normal termination of the program, codes
64-127 indicate abnormal termination of the program (such as parse
errors, I/O errors).</p><p>In case of normal program termination:
</p><ul class="itemize"><li class="li-itemize">
exit code 0 indicates that all foreground packages are found
installable;
</li><li class="li-itemize">exit code 1 indicates that at least one foreground package is found
uninstallable.
</li></ul>
<!--TOC section id="sec23" Tips and Tricks-->
<h2 id="sec23" class="section">6  Tips and Tricks</h2><!--SEC END --><p>
<a id="sec:tricks"></a>
</p>
<!--TOC subsection id="sec24" Encoding checks involving several packages-->
<h3 id="sec24" class="subsection">6.1  Encoding checks involving several packages</h3><!--SEC END --><p>
dose-debcheck only tests whether any package in the foreground set is
installable. However, sometimes one is interested in knowing whether
several packages are co-installable, that is whether there exists an
installation set that contains all these packages. One might also be
interested in an installation that does <em>not</em> contain a certain
package.</p><p>This can be encoded by creating a pseudo-package that
represents the query. </p><div class="example"><p><span style="font-weight:bold">Example:</span>
We wish to know whether it is possible to install at the same time
<span style="font-family:monospace">a</span> and <span style="font-family:monospace">b</span>, the latter in some version ≥ 42, but
without installing c. We create a pseudo package like this:
</p><pre class="verbatim">Package: query
Version: 1
Architecture: all
Depends: a, b(&gt;= 42)
Conflicts: c
</pre><p>Then we check for installability of that package with respect to the
repository:
</p><pre class="verbatim">echo "Package: query\nVersion: 1\nArchitecture: all\nDepends: a, b(&gt;=42)\nConflicts: c" | dose-debcheck --bg=repository
</pre><p>(Beware: This might not do exactly what you want, see below!)
</p></div><p>The problem with this encoding is as follows: if we ask dose-debcheck
for installability of some package depending on <span style="font-family:monospace">a</span> then this
dependency can a priori be satisfied by any of the available versions
of package <span style="font-family:monospace">a</span>, or even by some other package that provides
<span style="font-family:monospace">a</span> as a virtual package. Virtual packages can be excluded by
exploiting the fact that, in Debian, virtual packages are not
versioned. As a consequence, any package relation (like Depends)
containing a version constraint can only be matched by a real package,
and not by a virtual package. This means that the dependency on
<span style="font-family:monospace">b (&gt;= 42)</span> in the above example already can only be matched by
a real package. If we also want to restrict dependency on <span style="font-family:monospace">a</span>
to real packages only without knowing its possible versions, then we
may write <span style="font-family:monospace">Depends: a (&gt;=0) | a(&lt;0)</span>.</p><div class="example"><p><span style="font-weight:bold">Example:</span>
If we wish to know whether it is possible to install at the same
time some version of package <span style="font-family:monospace">a</span> and some version of package
<span style="font-family:monospace">b</span>, under the condition that these are real packages and not
virtual packages, then we may construct the following pseudo-package
and check its installability:
</p><pre class="verbatim">Package: query
Version: 1
Architecture: all
Depends: a(&gt;=0) | a(&lt;0), b(&gt;=0) | b(&lt;0)
</pre></div><p>Note that it is in theory possible, though admittedly quite unlikely,
that a package has a version number smaller than 0 (example:
0∼).</p><p>However, if we have several versions of package <span style="font-family:monospace">a</span> and several
versions of package <span style="font-family:monospace">b</span> then the above pseudo-package is
installable if it is possible to install at the same time <em>some
version</em> of <span style="font-family:monospace">a</span> and <em>some version</em> of <span style="font-family:monospace">b</span>. If we
want instead to check co-installability of any combination of versions
of package <span style="font-family:monospace">a</span> with versions of package <span style="font-family:monospace">b</span> then the
<span style="font-family:monospace">--coinst</span> option (see Section <a href="#sec%3Ainvocation-coinst">3.3</a>) is
better suited for the task.</p>
<!--TOC subsection id="sec25" Parsing dose-debcheck’s output in Python-->
<h3 id="sec25" class="subsection">6.2  Parsing dose-debcheck’s output in Python</h3><!--SEC END --><p>
<a id="sec:tricks-python"></a>
Debcheck’s output can be easily parsed from a Python program by using
the YAML parser (needs the Debian package <span style="font-family:monospace">python-yaml</span>).</p><div class="example"><p><span style="font-weight:bold">Example:</span>
If you have run debcheck with the option <span style="font-family:monospace">-f</span> (and possibly
with the <span style="font-family:monospace">-s</span> option in addition) you may obtain a report
containing one non-installable package (name and version) per line
like this:</p><pre class="verbatim">import yaml

doc = yaml.load(file('output-of-distcheck', 'r'))
if doc['report'] is not None:
  for p in doc['report']:
    if p['status'] == 'broken':
      print '%s %s is broken' (p['package'], p['version'])
</pre></div><p>A complete example of a python script that constructs a set of
pseudo-packages, runs dose-debcheck on it, and then processes the output
is given in the directory
<span style="font-family:monospace">doc/examples/potential-file-overwrites</span>.</p>
<!--TOC subsection id="sec26" Usage as a test in a shell script-->
<h3 id="sec26" class="subsection">6.3  Usage as a test in a shell script</h3><!--SEC END --><p>
Exit codes allow for a convenient integration of installation checks
as tests in shell scripts.</p><div class="example"><p><span style="font-weight:bold">Example:</span>
Suppose that you want to check installability of all <code>.deb</code> files
in the current directory with respect to the repository
<code>unstable.packages</code> before uploading your package described in
<code>mypackage.changes</code>:</p><pre class="verbatim">find . -name "*.deb" -exec dpkg-deb --info '{}' control \; -exec echo ""\; | \
  dose-debcheck --bg unstable.packages &amp;&amp; dput mypackage.changes
</pre></div>
<!--TOC section id="sec27" Credits-->
<h2 id="sec27" class="section">7  Credits</h2><!--SEC END --><p>
<a id="sec:credits"></a></p><p>Jérôme Vouillon is the author of the solving engine. He also wrote the
first version of the program (called <span style="font-variant:small-caps">debcheck</span> and
<span style="font-variant:small-caps">rpmcheck</span> at that time), which was released in November 2005.</p><p>The initial development of this tool was supported by the research
project <em>Environment for the development and Distribution of
Open Source software (EDOS)</em>, funded by the European Commission
under the IST activities of the 6th Framework Programme. Further
development and maintenance of the software, together with new
applications building on top of it, was funded by the research project
<em>Managing the Complexity of the Open Source Infrastructure
(Mancoosi)</em>, funded by the European Commission under the IST
activities of the 7th Framework Programme, grant agreement 214898.</p><p>The work on this software was partly performed at
<a href="http://www.irill.org">IRILL</a>, the Center for Research and
Innovation on Free Software.</p>
<!--TOC section id="sec28" Further Reading-->
<h2 id="sec28" class="section">8  Further Reading</h2><!--SEC END --><p>
The dose-debcheck tool, the underlying theory and its application, was
described in [<a href="#edos2006ase">MBD+06</a>].</p><p>The paper [<a href="#edos-debconf08">TZ08</a>] gives an overview of the theory, and
explains how dose-debcheck is used for various aspect of quality
assurance in Debian.</p><p>Checking the relationships between software components is of course
also possible and useful for other models of software packages than
Debian packages. In fact, the dose-debcheck tool is only one flavor of a
more general tool called dose-distcheck which may perform these checks
as well for RPM packages and Eclipse plugins, and in the future
possibly for even more formats. These formats have many things in
common, and the authors of dose-debcheck are convinced that the right
architecture for tools dealing with logical aspects of packages is a
modular one. Such a modular architecture should be centered around a
common universal format for describing the relationships between
packages. This architecture is described in [<a href="#mpm-cbse11">ACTZ11</a>].</p>
<!--TOC section id="sec29" Copyright and Licence-->
<h2 id="sec29" class="section">9  Copyright and Licence</h2><!--SEC END --><p>
<a id="sec:copyright"></a>
Copyright © 2010, 2011, 2012
Pietro Abate <code>&lt;pietro.abate@pps.univ-paris-diderot.fr&gt;</code>,
Ralf Treinen <code>&lt;ralf.treinen@pps.univ-paris-diderot.fr&gt;</code>,
and Université Paris-Diderot, for this documentation.</p><p>This documentation is free software: you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version.</p><p>The software itself is, of course, free software. You can redistribute
and/or modify dose-distcheck (including dose-debcheck), as well as the
underlying library called <span style="font-family:monospace">dose</span>, under the terms of the GNU
Lesser General Public License as published by the Free Software
Foundation, either version 3 of the License, or (at your option) any
later version. A special linking exception to the GNU Lesser General
Public License applies to the library, see the precise licence
information of <span style="font-family:monospace">dose</span> for details.</p><!--TOC section id="sec30" References-->
<h2 id="sec30" class="section">References</h2><!--SEC END --><dl class="thebibliography"><dt class="dt-thebibliography">
<a id="mpm-cbse11">[ACTZ11]</a></dt><dd class="dd-thebibliography">
Pietro Abate, Roberto Di Cosmo, Ralf Treinen, and Stefano Zacchiroli.
MPM: a modular package manager.
In Ivica Crnkovic, Judith A. Stafford, Antonia Bertolino, and Kendra
M. L. Cooper, editors, <em>Proceedings of the 14th International ACM Sigsoft
Symposium on Component Based Software Engineering (CBSE 2011)</em>, pages
179–188, Boulder, CO, USA, June 2011. ACM.
[<a href="http://www.mancoosi.org/papers/cbse11.pdf">PDF</a>].</dd><dt class="dt-thebibliography"><a id="ubuntu:multiarch">[Lan11]</a></dt><dd class="dd-thebibliography">
Steve Langasek.
Multiarch spec, 2011.
Available at <a href="https://wiki.ubuntu.com/MultiarchSpec"><span style="font-family:monospace">https://wiki.ubuntu.com/MultiarchSpec</span></a>.</dd><dt class="dt-thebibliography"><a id="edos2006ase">[MBD<sup>+</sup>06]</a></dt><dd class="dd-thebibliography">
Fabio Mancinelli, Jaap Boender, Roberto Di Cosmo, Jérôme Vouillon, Berke
Durak, Xavier Leroy, and Ralf Treinen.
Managing the complexity of large free and open source package-based
software distributions.
In <em>21st IEEE/ACM International Conference on Automated Software
Engeineering (ASE)</em>, pages 199–208, Tokyo, Japan, 2006. IEEE.</dd><dt class="dt-thebibliography"><a id="edos-debconf08">[TZ08]</a></dt><dd class="dd-thebibliography">
Ralf Treinen and Stefano Zacchiroli.
Solving package dependencies: from EDOS to Mancoosi.
In <em>Proceedings of </em><em>DebConf8</em><em>: 9th annual conference of the
</em><em>D</em><em>ebian project developers</em>, Mar del Plata, Argentina, August 2008.
[<a href="http://upsilon.cc/~zack/research/publications/debconf8-mancoosi.pdf">PDF</a>].</dd></dl><!--CUT END -->
<!--HTMLFOOT-->
<!--ENDHTML-->
<!--FOOTER-->
<hr style="height:2"><blockquote class="quote"><em>This document was translated from L<sup>A</sup>T<sub>E</sub>X by
</em><a href="http://hevea.inria.fr/index.html"><em>H</em><em><span style="font-size:small"><sup>E</sup></span></em><em>V</em><em><span style="font-size:small"><sup>E</sup></span></em><em>A</em></a><em>.</em></blockquote></body>
</html>
dose-distcheck 3.1.3-7build1 / usr / share / doc / dose-distcheck / debcheck-primer.html
