You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

440 lines
16 KiB

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