File: Requirements

package info (click to toggle)
pkg-order 1.02
  • links: PTS
  • area: main
  • in suites: hamm, slink
  • size: 484 kB
  • ctags: 172
  • sloc: perl: 4,094; makefile: 81
file content (163 lines) | stat: -rw-r--r-- 6,745 bytes parent folder | download | duplicates (2)
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.