1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
Requirements
------------
* The package should write out an order to install new packages
* The package should be able to detect dependency loops in the new
package list.
* The package should be able to work stand alone, however, it should
provide libraries so that the dependency checks and topological
sorts on new packages are available to other scripts/programs as
well. (like dftp, auto build a whole distribution from scratch,
other dependency checkers).
* The package should be a user interface only, all functionality
should be wrapped into the libraries so that alternate user
interfaces would be easy (using ncurses, perltk, dialog, CGI, etc
one can have multiple front ends).
* The packages should be able to handle Pre-Dependencies in the sense
that a set of packages may have to be installed in installments, in
order to have the target of a Pre-Dependency be fully configured and
installed before the dependent package is installed (or else the
installation will break). The package should be able to determine
and specify these break points.
* The package should make no assumptions about the fields in the
package description, except possibly fields that it needs for
operation (Package, Status, Pre-Depends, Depends, Recommends,
Suggests, Conflicts, and Replaces).
* The package should also be able to do dependency satisfaction checks
on other relationship fields in the package (Recommends, and
Suggests) as well, if asked by the user.
* The package should use dpkg and friends to do version checks rather
than hard coding it internally -- (in case things change, like the
recent introduction of epochs).
* The package should be able to read installed packages from
/var/lib/dpkg/status -- or one or more files in the same format
supplied by the user (*must* have the status field)
* The libraries must support incremental construction of both the New
and Installed package lists.
* The package (or at least the libraries underneath) should provide an
easy means of adding/deleting packages to the list of packages to be
installed.
* This package should do nothing else than produce an ordering list
(apart from error messages about failed dependency checks, and
information asked by the user). It should not modify anything, apart
from maybe temp files in /tmp.
* The package should be flexible about handling anomalies (a failed
dependency check could cause the process to stop, or the package
that failed the dependency (or conflict) to be marked as failed, and
ignored from further processing, and a ordering generated for the
rest of the packages.
* The package dependency checks may be run independently on
several headers (Pre-depends, Depends, etc) with possibly different
action being taken depending on the headers (a failed suggestion
produces nothing more than a warning, for example).
* The ordering information may similarily be gathered over several
passes over different headers.
* The package should offer configurable levels of verbosity and debug
messages.
* The package should keep track of which package provided a package
and use that in dependency ordering.
* The package should be aware of virtual packages.
Nice qualities of the current implementation:
---- --------- -- --- ------- --------------
* One should be able to run it as a ordering tool, a dependency
checker, or both.
* One may pass in the installed files as a comma separated list to the
application, but if you roll your own application, using the library, you
could process the installed files one by one, marking failed new
packages on each run. Finally, one could just run the ordering pass
on the packages that survive (you could do this in one fell swoop,
if you wish, as well, as the code is written).
Inputs:
------
* The new packages list -- the packages to be installed.
* The list of installed packages -- the packages on the system
* The virtual packages list
The current implementation of the ordering tool reads the new
packages list from a Package file given on the command line, and the
installed packages list from /var/lib/dpkg/status (ignoring packages
in status that are not installed OK), and uses the built in list of
virtual packages, unless given an alternative on the command
line. Also there an option of specifying a comma separated list of
Package files as installed packages, or another option to specify a
comma separated list of status files.
The underlying Library supports adding packages to the list
one at a time (we split up the Packages file internally anyway), by
supplying a string containing the output of dpkg --info or dpkg
-s. In fact the test method supplies a made up package info string to
add a package for a test.
Process:
-------
In the checking dependency phase, for each package in
the new packages list, we look at the dependencies, and ensure that
each dependency is satisfied in either the new packages list or the
installed list.
* Test Pre-Dependencies. (add to package order info; need to keep
this static)
failures: mark packages not to be processed anymore.
Default action: exit on any error
Optionally: dynamically ignore package, mark as failed,
continue.
* Test Conflicts:
failures: mark packages not to be processed anymore.
Default action: continue
Need to handle conflict and replace: remove mark if we also replace.
That is, a conflict is bad, but a conflict *AND* a replacement of
the same package should be fine. Merely replacing a package
with another is also not a problem.
Optionally: fail hard.
* Test Recommends: (optional)
failures: message, Default: do not mark and do not exit
* Test Suggests: (optional)
failures: message, Default: do not mark and do not exit
* Test Dependencies:
failures: mark packages not to be processed anymore.
Default action: exit on any error
The ordering action is tied to this step. If the directive is
satisfied from the new packages list, a line is added to the
ordering info with the format
<package-that-needs-to-be-installed-first> <current-package>
The information is later printed to an output file, and then we
run tsort on the output file, giving us an order to install new
packages in.
Responses to failures:
--------- -- --------
The user should be able to run any or all of these steps;
Failure at any step should be configurable Responses could be
1) stop
2) mark package as bad
3) warn verbosely, but no mark.
4) Summarize number of failures
5) ignore (same as not running this step)
5 possible runs, each with 5 error Responses.
|
