Proposal for the next generation of edos-debcheck
This is a proposal for the user interface of the edos-debchcek that will be based on the dose3 library.
Usage -- proposal for a manpage
edos-debcheck [option] ... [filename] ...
Checks whether all members of a set of packages, each of which is described by a deb-control(5) stanza, are installable from the point of view of inter-package relations expressed in the package stanzas. A package may be either in the foreground (in which case the tool checks installability of that package, and may also use it to satisfy the dependencies of other packages), or in the background (in which case the tool does not check installability of that package but may use it to satisfy dependencies of other packages).
The contents of the files listed on the command line constitutes the set of foreground packages, "-" indicates that in addition foreground package stanzas are to be read from standard input. Without any additional options, the set of background packages is empty. Packages may be pushed from the foreground into the background by using filter options (see "input options" below).
By default, only the number of non-installable foreground packages is displayed, see "output options" below for how to change this.
Options and filenames can be given in any order. In any case, any option applies to the complete problem instance.
Input Options
-b, --background <file>
add package stanzas from <file> to the background. These packages will not be checked themselves for installability but will only be used to resolve dependencies. May be used multiple times. If a package is both given on a background and a foreground position then it gets foreground status.
-m, --match <filterexpression>
push all packages that are not matched by <filterexpression> from the foreground into the background.
<filterexpression> is a list of selectors, separated by the character '|'. This expression matches a package when one of its selectors matches the package. A selector is either a packagename, matching all packages with exactly that package name, or 'source=srcname', matching all packages having srcname as value of their Source field.
Output Options
-f, --failures
- print the list of non-installable foreground packages.
-s, --successes
- print the list of installable foreground packages. It is possible to specify -f and -s together in order to obtain installability information for all foreground packages.
-e, --explain
- print an explanation; this is a consistent installation set for each installable foreground package when option -s is used, and the non-satisfiable part of the dependency and conflict clauses in case the package is not installable when option -f is used. Useful only in combination with at least one of the options -f and -s.
-q, --quiet
- be less verbose. May be iterated.
-v, --verbose
- be more verbose. May be iterated.
Misc Options
-h, --help
- Summary of command usage
--version
- Print version
Remarks on Usage
- For the future we will have to think how more elaborate filters can be used. There are two options:
- The set of filterexpressions will be extended, allowing for filtering on any field, regular expressions for matching strings, testing absence of fields, checking that a package is in the latest version, as well as combination by negation and logical conjunction. That extension should be conervative, that is expressions as described above should continue to be valid expressions with the same meaning.
- Rely on using grep-dctrl to filter packages. This can be easiliy done since one can just put all packages as background packages, and use grep-dctrl to select a set of foreground packages. This works fine since when a package appears both in foreground and in background position then it gets foreground status.
- We have not planned a special syntax for installing several packages at the same time. The reason is that this can be easily encoded by turning such a request into a pseudo package, and asking for installability of that pseudo package. TODO: we should explain further how to do this
We might in the future have to add an option "-a <arch>" with the meaning "assume that you are on architecture <arch>". This means ignoring all packages who's architecture field is inconsistent with <arch>, and ignoring all package relations which are constrained to architectures that are all inconsistent with <arch>. People are talking about a future extension of the *binary* package control format where you can write "Depends: foobar [i386]". So far this is only possible in Build-{Depends,Conflicts,...}. This would be useful for arch=all packages, since for the others the constraint is already expanded when constructing the Packages/Release file.
- TODO: we have to decide what exactly happens when a pair (packagename,version) appears twice in the input. The options are:
- take the first ocurrence
- take the last occurrence
- check that all occurrences are equal (at least on the fields relevant fro debcheck), and issue an error when this is not the case
- TODO: write a real user documentation document.
Output Format
We intend to drop the currently optional XML output, and have one single YAML output format which is both user readable and machine parsable.
The possible errors are conflicts, dependencies and missing packages the vpkg is the dependency as it is reported in the control stanza, the "packages" are the result of the expansion of the vpkg in the current universe. For example, below the package x has a dependency problem related to packages b = 1 and b = 2 , and a conflict problem between packages b = 1 and c = 1 ... I made this up just to explain the format.
YAML Scheme
type: map
mapping:
"total-packages": { type: int, required: true }
"broken-packages": { type: int, required: true }
"distribution": { type: text }
"release": { type: text }
"architecture": { type: text }
"report":
type: seq
sequence:
- type: map
mapping:
"package": { type: str, required: true }
"version": { type: text, required: true }
"architecture": { type: text, required: false }
"source": { type: text, required: false }
"status": { type: str, enum: [ broken, ok ], required: true }
"installationset":
type: seq
sequence:
- type: map
mapping:
"package": { type: str, required: true }
"version": { type: text, required: true }
"architecture": { type: text, required: false }
"reasons":
type: seq
sequence:
- type: map
mapping:
"conflict":
type: map
mapping:
"pkg1":
type: map
required: true
mapping:
"package": { type: str, required: true }
"version": { type: text, required: true }
"architecture": { type: text, required: false }
"pkg2":
type: map
required: true
mapping:
"package": { type: str, required: true }
"version": { type: text, required: true }
"architecture": { type: text, required: false }
"depchain1":
type: seq
sequence:
- type: map
mapping:
"depchain":
type: seq
sequence:
- type: map
mapping:
"package": { type: str, required: true }
"version": { type: text, required: true }
"architecture": { type: text, required: false }
"depends": { type: str, required: false}
"depchain2":
type: seq
sequence:
- type: map
mapping:
"depchain":
type: seq
sequence:
- type: map
mapping:
"package": { type: str, required: true }
"version": { type: text, required: true }
"architecture": { type: text, required: false }
"depends": { type: str, required: false}
"missing":
type: map
mapping:
"pkg":
type: map
required: true
mapping:
"package": { type: str, required: true }
"version": { type: text, required: true }
"architecture": { type: text, required: false }
"missingdep": { type: str, required: false}
"depchains":
type: seq
sequence:
- type: map
mapping:
"depchain":
type: seq
sequence:
- type: map
mapping:
"package": { type: str, required: true }
"version": { type: text, required: true }
"architecture": { type: text, required: false }
"depends": { type: str, required: false}There are two possible source of un-installability for a package. Either one package is missing or there is a conflict between two packages on which the root package depends (directly or indirectly). In both cases distcheck print a dependency path from the root to the offending packages.
Example of output
report:
-
package: knights-themepack
version: 0.5.9-1
architecture: amd64
source: knights-themepack (= 0.5.9-1)
status: broken
reasons:
-
missing:
pkg:
package: knights
version: 0.6-8.2+b1
architecture: amd64
missingdep: kdebase-kio-plugins
paths:
-
depchain:
-
package: knights-themepack
version: 0.5.9-1
architecture: amd64
depends: knights
-
package: xserver-xorg-input-fpit
version: 1:1.3.0-2
architecture: amd64
source: xserver-xorg-input-fpit (= 1:1.3.0-2)
status: broken
reasons:
-
conflict:
pkg1:
package: xserver-xorg-input-fpit
version: 1:1.3.0-2
architecture: amd64
pkg2:
package: xserver-xorg-core
version: 2:1.7.7-5
architecture: amd64
paths2:
-
depchain:
-
package: xserver-xorg-input-fpit
version: 1:1.3.0-2
architecture: amd64
depends: xserver-xorg-core (>= 2:1.5.99.901)
total-packages: 29589
broken-packages: 143to check the conformity of the example to the data structure we can use kwalify : http://www.kuwata-lab.com/kwalify/ruby/users-guide.01.html#schema
$kwalify -lf distcheck.yaml ex.yaml ex.yaml#0: valid.
EDOS-builddebcheck
This is almost as debcheck, except that filename arguments on the command line would indicate files containing source stanzas (which are foregound), and -i would be used for files containing binary packages (which are background).