doc/design.dbk

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