]>
Commit | Line | Data |
---|---|---|
1 | <?xml version="1.0" encoding="UTF-8"?> | |
2 | <!-- -*- DocBook -*- --> | |
3 | <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" | |
4 | "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ | |
5 | <!ENTITY % aptverbatiment SYSTEM "apt-verbatim.ent"> %aptverbatiment; | |
6 | ]> | |
7 | ||
8 | <book lang="en"> | |
9 | ||
10 | <title>The APT project design document</title> | |
11 | ||
12 | <bookinfo> | |
13 | ||
14 | <authorgroup> | |
15 | <author> | |
16 | <personname>Manoj Srivastava</personname><email>srivasta@debian.org</email> | |
17 | </author> | |
18 | </authorgroup> | |
19 | ||
20 | <releaseinfo>Version &apt-product-version;</releaseinfo> | |
21 | ||
22 | <abstract> | |
23 | <para> | |
24 | This document is an overview of the specifications and design goals of the APT | |
25 | project. It also attempts to give a broad description of the implementation | |
26 | as well. | |
27 | </para> | |
28 | </abstract> | |
29 | ||
30 | <copyright><year>1997</year><holder>Manoj Srivastava</holder></copyright> | |
31 | ||
32 | <legalnotice> | |
33 | <title>License Notice</title> | |
34 | <para> | |
35 | APT, including this document, is free software; you may redistribute it and/or | |
36 | modify it under the terms of the GNU General Public License as published by the | |
37 | Free Software Foundation; either version 2, or (at your option) any later | |
38 | version. | |
39 | </para> | |
40 | <para> | |
41 | This is distributed in the hope that it will be useful, but <emphasis>without | |
42 | any warranty</emphasis>; without even the implied warranty of merchantability | |
43 | or fitness for a particular purpose. See the GNU General Public License for | |
44 | more details. | |
45 | </para> | |
46 | <para> | |
47 | You should have received a copy of the GNU General Public License with your | |
48 | Debian system, in <literal>/usr/share/common-licenses/GPL</literal>, or with | |
49 | the <command>debiandoc-sgml</command> source package as the file | |
50 | <literal>COPYING</literal>. If not, write to the Free Software Foundation, | |
51 | Inc., 675 Mass Ave, Cambridge, MA 02139, USA. | |
52 | </para> | |
53 | </legalnotice> | |
54 | ||
55 | </bookinfo> | |
56 | ||
57 | <chapter id="introduction"><title>Introduction</title> | |
58 | <para> | |
59 | APT is supposed to be a replacement for dselect, and not a replacement for | |
60 | dpkg. However, since addition functionality has been required for APT, and | |
61 | given the fact that this is very closely related to dpkg, it is not | |
62 | unreasonable to expect that additional functionality in the underlying dpkg | |
63 | would also be requested. | |
64 | </para> | |
65 | <para> | |
66 | Deity/dselect are the first introduction that people have to Debian, and | |
67 | unfortunately this first impression contributes greatly to the public | |
68 | perception of the distribution. It is imperative that this be a showcase for | |
69 | Debian, rather than frighten novices away (which has been an accusation often | |
70 | levelled at the current system) | |
71 | </para> | |
72 | </chapter> | |
73 | ||
74 | <chapter id="ch2"><title>Requirements</title> | |
75 | <orderedlist numeration="arabic"> | |
76 | <listitem> | |
77 | <para> | |
78 | APT should be a replacement for dselect. Therefore it should have all the | |
79 | functionality that dselect has currently. This is the primary means of | |
80 | interaction between the user and the package management system, and it should | |
81 | be able to handle all tasks involved in installing, upgrading, and routine | |
82 | management without having the users take recourse to the underlying management | |
83 | system. | |
84 | </para> | |
85 | </listitem> | |
86 | <listitem> | |
87 | <para> | |
88 | It should be easier to use and less confusing for novice users. The primary | |
89 | stimulus for the creation of APT was the perceived intractability, complexity, | |
90 | and non-intuitive behavior of the existing user interface, and as such, human | |
91 | factors must be a primary mandate of APT. | |
92 | </para> | |
93 | </listitem> | |
94 | <listitem> | |
95 | <para> | |
96 | It should be able to group packages more flexibly, and possibly allow | |
97 | operations based on a group. One should be able to select, or deselect, | |
98 | a coherent group of related packages simultaneously, allowing one to add, | |
99 | remove, or upgrade functionality to a machine as one step. | |
100 | </para> | |
101 | </listitem> | |
102 | <listitem> | |
103 | <para> | |
104 | This would allow APT to handle <emphasis>standard installations</emphasis>, | |
105 | namely, one could then install a set of packages to enable a machine to | |
106 | fulfill specific tasks. Define a few standard installations, and which | |
107 | packages are included therein. The packages should be internally consistent. | |
108 | </para> | |
109 | </listitem> | |
110 | <listitem> | |
111 | <para> | |
112 | Make use of a keywords field in package headers; provide a standard list of | |
113 | keywords for people to use. This could be the underpinning to allow the | |
114 | previous two requirements to work (though the developers are not constrained | |
115 | to implement the previous requirements using keywords) | |
116 | </para> | |
117 | </listitem> | |
118 | <listitem> | |
119 | <para> | |
120 | Use dependencies, conflicts, and reverse dependencies to properly order | |
121 | packages for installation and removal. This has been a complaint in the past | |
122 | that the installation methods do not really understand dependencies, causing | |
123 | the upgrade process to break, or allowing the removal of packages that left the | |
124 | system in an untenable state by breaking the dependencies on packages that were | |
125 | dependent on the package being removed. A special emphasis is placed on | |
126 | handling pre-dependencies correctly; the target of a predependency has to be | |
127 | fully configured before attempting to install the pre-dependent package. Also, | |
128 | <emphasis>configure immediately</emphasis> requests mentioned below should be | |
129 | handled. | |
130 | </para> | |
131 | </listitem> | |
132 | <listitem> | |
133 | <para> | |
134 | Handle replacement of a package providing a virtual package with another (for | |
135 | example, it has been very difficult replacing <command>sendmail</command> with | |
136 | <command>smail</command>, or vice versa), making sure that the dependencies are | |
137 | still satisfied. | |
138 | </para> | |
139 | </listitem> | |
140 | <listitem> | |
141 | <para> | |
142 | Handle source lists for updates from multiple sources. APT should also be able | |
143 | to handle diverse methods of acquiring new packages; local filesystem, | |
144 | mountable CD-ROM drives, FTP accessible repositories are some of the methods | |
145 | that come to mind. Also, the source lists can be separated into categories, | |
146 | such as main, contrib, non-us, non-local, non-free, my-very-own, etc. APT | |
147 | should be set up to retrieve the Packages files from these multiple source | |
148 | lists, as well as retrieving the packages themselves. | |
149 | </para> | |
150 | </listitem> | |
151 | <listitem> | |
152 | <para> | |
153 | Handle base of source and acquire all Packages files underneath. (possibly | |
154 | select based on architecture), this should be a simple extension of the | |
155 | previous requirement. | |
156 | </para> | |
157 | </listitem> | |
158 | <listitem> | |
159 | <para> | |
160 | Handle remote installation (to be implemented maybe in a future version, it | |
161 | still needs to be designed). This would ease the burden of maintaining | |
162 | multiple Debian machines on a site. In the authors opinion this is a killer | |
163 | difference for the distribution, though it may be too hard a problem to be | |
164 | implemented with the initial version of APT. However, some thought must be | |
165 | given to this to enable APT to retain hooks for future functionality, or at | |
166 | least to refrain from methods that may preclude remote activity. It is | |
167 | desirable that adding remote installation not require a redesign of APT from | |
168 | the ground up. | |
169 | </para> | |
170 | </listitem> | |
171 | <listitem> | |
172 | <para> | |
173 | Be scalable. Dselect worked a lot better with 400 packages, but at last count | |
174 | the number of packages was around twelve hundred and climbing. This also | |
175 | requires APT to pay attention to the needs of small machines which are low on | |
176 | memory (though this requirement shall diminish as we move towards bigger | |
177 | machines, it would still be nice if Debian worked on all old machines where | |
178 | Linux itself would work). | |
179 | </para> | |
180 | </listitem> | |
181 | <listitem> | |
182 | <para> | |
183 | Handle install immediately requests. Some packages, like watchdog, are | |
184 | required to be working for the stability of the machine itself. There are | |
185 | others which may be required for the correct functioning of a production | |
186 | machine, or which are mission critical applications. APT should, in these | |
187 | cases, upgrade the packages with minimal downtime; allowing these packages to | |
188 | be one of potentially hundreds of packages being upgraded concurrently may | |
189 | not satisfy the requirements of the package or the site. (Watchdog, for | |
190 | example, if not restarted quickly, may cause the machine to reboot in the | |
191 | midst of installation, which may cause havoc on the machine) | |
192 | </para> | |
193 | </listitem> | |
194 | </orderedlist> | |
195 | </chapter> | |
196 | ||
197 | <chapter id="ch3"><title>Procedural description</title> | |
198 | <variablelist> | |
199 | <varlistentry> | |
200 | <term>Set Options</term> | |
201 | <listitem> | |
202 | <para> | |
203 | This process handles setting of user or site options, and configuration of all | |
204 | aspects of APT. It allows the user to set the location and order of package | |
205 | sources, allowing them to set up source list details, like ftp site locations, | |
206 | passwords, etc. Display options may also be set. | |
207 | </para> | |
208 | </listitem> | |
209 | </varlistentry> | |
210 | <varlistentry> | |
211 | <term>Updates</term> | |
212 | <listitem> | |
213 | <para> | |
214 | Build a list of available packages, using source lists or a base location and | |
215 | trawling for Packages files (needs to be aware of architecture). This may | |
216 | involve finding and retrieving Packages files, storing them locally for | |
217 | efficiency, and parsing the data for later use. This would entail contacting | |
218 | various underlying access modules (ftp, cdrom mounts, etc) Use a backing store | |
219 | for speed. This may also require downloading the actual package files locally | |
220 | for speed. | |
221 | </para> | |
222 | </listitem> | |
223 | </varlistentry> | |
224 | <varlistentry> | |
225 | <term>Local status</term> | |
226 | <listitem> | |
227 | <para> | |
228 | Build up a list of packages already installed. This requires reading and | |
229 | writing the local?? status file. For remote installation, this should | |
230 | probably use similar mechanisms as the Packages file retrieval does. Use | |
231 | the backing store for speed. One should consider multiple backing stores, | |
232 | one for each machine. | |
233 | </para> | |
234 | </listitem> | |
235 | </varlistentry> | |
236 | <varlistentry> | |
237 | <term>Relationship determination</term> | |
238 | <listitem> | |
239 | <para> | |
240 | Determine forward and reverse dependencies. All known dependency fields should | |
241 | be acted upon, since it is fairly cheap to do so. Update the backing store | |
242 | with this information. | |
243 | </para> | |
244 | </listitem> | |
245 | </varlistentry> | |
246 | <varlistentry> | |
247 | <term>Selection</term> | |
248 | <listitem> | |
249 | <para> | |
250 | Present the data to the user. Look at Behan Webster's documentation for the | |
251 | user interface procedures. (Note: In the authors opinion deletions and reverse | |
252 | dependencies should also be presented to the user, in a strictly symmetric | |
253 | fashion; this may make it easier to prevent a package being removed that breaks | |
254 | dependencies) | |
255 | </para> | |
256 | </listitem> | |
257 | </varlistentry> | |
258 | <varlistentry> | |
259 | <term>Ordering of package installations and configuration</term> | |
260 | <listitem> | |
261 | <para> | |
262 | Build a list of events. Simple topological sorting gives order of packages | |
263 | in dependency order. At certain points in this ordering, | |
264 | predependencies/immediate configure directives cause an break in normal | |
265 | ordering. We need to insert the uninstall/purge directive in the stream | |
266 | (default: as early as possible). | |
267 | </para> | |
268 | </listitem> | |
269 | </varlistentry> | |
270 | <varlistentry> | |
271 | <term>Action</term> | |
272 | <listitem> | |
273 | <para> | |
274 | Take the order of installations and removals and build up a stream of events | |
275 | to send to the packaging system (dpkg). Execute the list of events if | |
276 | successful. Do not partially install packages and leave system in broken | |
277 | state. Go to The Selection step as needed. | |
278 | </para> | |
279 | </listitem> | |
280 | </varlistentry> | |
281 | </variablelist> | |
282 | </chapter> | |
283 | ||
284 | <chapter id="ch4"><title>Modules and interfaces</title> | |
285 | <variablelist> | |
286 | <varlistentry> | |
287 | <term>The user interface module</term> | |
288 | <listitem> | |
289 | <para> | |
290 | Look at Behan Webster's documentation. | |
291 | </para> | |
292 | </listitem> | |
293 | </varlistentry> | |
294 | <varlistentry> | |
295 | <term>Widget set</term> | |
296 | <listitem> | |
297 | <para> | |
298 | Related closely to above Could some one present design decisions of the widget | |
299 | set here? | |
300 | </para> | |
301 | </listitem> | |
302 | </varlistentry> | |
303 | <varlistentry> | |
304 | <term>pdate Module</term> | |
305 | <listitem> | |
306 | <para> | |
307 | Distinct versions of the same package are recorded separately, but if multiple | |
308 | Packages files contain the same version of a package, then only the first one | |
309 | is recorded. For this reason, the least expensive update source should be | |
310 | listed first (local file system is better than a remote ftp site) | |
311 | </para> | |
312 | <para> | |
313 | This module should interact with the user interface module to set and change | |
314 | configuration parameters for the modules listed below. It needs to record that | |
315 | information in an on disk data file, to be read on future invocations. | |
316 | </para> | |
317 | <orderedlist numeration="arabic"> | |
318 | <listitem> | |
319 | <para> | |
320 | FTP methods | |
321 | </para> | |
322 | </listitem> | |
323 | <listitem> | |
324 | <para> | |
325 | mount and file traversal module(s)? | |
326 | </para> | |
327 | </listitem> | |
328 | <listitem> | |
329 | <para> | |
330 | Other methods ??? | |
331 | </para> | |
332 | </listitem> | |
333 | </orderedlist> | |
334 | </listitem> | |
335 | </varlistentry> | |
336 | <varlistentry> | |
337 | <term>Status file parser/generator</term> | |
338 | <listitem> | |
339 | <para> | |
340 | The status file records the current state of the system, listing the packages | |
341 | installed, etc. The status file is also one method of communicating with dpkg, | |
342 | since it is perfectly permissible for the user to use APT to request packages | |
343 | be updated, put others on hold, mark other for removal, etc, and then run | |
344 | <literal>dpkg -BORGiE</literal> on a file system. | |
345 | </para> | |
346 | </listitem> | |
347 | </varlistentry> | |
348 | <varlistentry> | |
349 | <term>Package file parser/generator</term> | |
350 | <listitem> | |
351 | <para> | |
352 | Related to above. Handle multiple Packages files, from different | |
353 | sources. Each package contains a link back to the packages file structure | |
354 | that contains details about the origin of the data. | |
355 | </para> | |
356 | </listitem> | |
357 | </varlistentry> | |
358 | <varlistentry> | |
359 | <term>Dependency module</term> | |
360 | <listitem> | |
361 | <itemizedlist> | |
362 | <listitem> | |
363 | <para> | |
364 | dependency/conflict determination and linking | |
365 | </para> | |
366 | </listitem> | |
367 | <listitem> | |
368 | <para> | |
369 | reverse dependency generator. Maybe merged with above | |
370 | </para> | |
371 | </listitem> | |
372 | </itemizedlist> | |
373 | </listitem> | |
374 | </varlistentry> | |
375 | <varlistentry> | |
376 | <term>Package ordering Module</term> | |
377 | <listitem> | |
378 | <para> | |
379 | Create an ordering of the actions to be taken. | |
380 | </para> | |
381 | </listitem> | |
382 | </varlistentry> | |
383 | <varlistentry> | |
384 | <term>Event generator</term> | |
385 | <listitem> | |
386 | <para> | |
387 | module to interact with dpkg | |
388 | </para> | |
389 | </listitem> | |
390 | </varlistentry> | |
391 | </variablelist> | |
392 | </chapter> | |
393 | ||
394 | <chapter id="ch5"><title>Data flow and conversions analysis.</title> | |
395 | <screen> | |
396 | ____________ | |
397 | __\|ftp modules| | |
398 | / /|___________| | |
399 | _ ____________ / ________________ | |
400 | | update | / |mount/local file| | |
401 | |==========================>| module |/_____\| traversals | | |
402 | | |_____________| /|________________| | |
403 | | ^ ^ | |
404 | | | | ______________ | |
405 | ______|_______ _ _____ ______ | _____v________ \| | | |
406 | |Configuration | |configuration| | |Packages Files| ===|Status file | | |
407 | | module |<=>| data | | |______________| / /|____________| | |
408 | |______________| |_____________| | ^ / | |
409 | ^ | | / | |
410 | | | _______v_______|/_ | |
411 | | | | | ________________ | |
412 | | | | |/_\| Dependency | | |
413 | | | |backing store |\ /| Module | | |
414 | | | |______________| _|_______________| | |
415 | | \ ^ /| ^ | |
416 | | \ | / | | |
417 | | _\|____v_______|/__ ____v_______ | |
418 | |_____________________________\| User interaction| | dpkg | | |
419 | /|_________________|<==> Invoker | | |
420 | |___________| | |
421 | </screen> | |
422 | <para> | |
423 | dpkg also interacts with status and available files. | |
424 | </para> | |
425 | <para> | |
426 | The backing store and the associated data structures are the core of APT. All | |
427 | modules essentially revolve around the backing store, feeding it data, adding | |
428 | and manipulating links and relationships between data in the backing store, | |
429 | allowing the user to interact with and modify the data in the backing store, | |
430 | and finally writing it out as the status file and possibly issuing directives | |
431 | to dpkg. | |
432 | </para> | |
433 | <para> | |
434 | The other focal point for APT is the user interface. | |
435 | </para> | |
436 | </chapter> | |
437 | ||
438 | </book> |