[back]
[Abstract]
[Copyright Notice]
[Contents]
[next]
The APT project design document - Chapter 2
Requirements
- APT should be a replacement for dselect. Therefore it
should have all the functionality that dselect has
currently. This is the primary means of interaction
between the user and the package management system, and
it should be able to handle all tasks involved in
installing, upgrading, and routine management without
having the users take recourse to the underlying
management system.
- It should be easier to use and less confusing for novice
users. The primary stimulus for the creation of APT
was the perceived intractability, complexity, and
non-intuitive behavior of the existing user interface,
and as such, human factors must be a primary mandate of
APT.
- It should be able to group packages more flexibly, and
possibly allow operations based on a group. One should
be able to select, or deselect, a coherent group of
related packages simultaneously, allowing one to add,
remove, or upgrade functionality to a machine as one
step.
- This would allow APT to handle standard
installations, namely, one could then install a
set of packages to enable a machine to fulfill specific
tasks. Define a few standard installations, and which
packages are included therein. The packages should be
internally consistent.
- Make use of a keywords field in package headers; provide
a standard list of keywords for people to use. This
could be the underpinning to allow the previous two
requirements to work (though the developers are not
constrained to implement the previous requirements using
keywords)
- Use dependencies, conflicts, and reverse dependencies to
properly order packages for installation and
removal. This has been a complaint in the past that the
installation methods do not really understand
dependencies, causing the upgrade process to break, or
allowing the removal of packages that left the system in
an untenable state by breaking the dependencies on
packages that were dependent on the package being
removed. A special emhasis is placed on handling
pre-dependencies correctly; the target of a
predependency has to be fully configured before
attempting to install the pre-dependent package. Also,
configure immediately requests mentioned below
should be handled.
- Handle replacement of a package providing a virtual
package with another (for example, it has been very
difficult replacing
sendmail
with
smail
, or vice versa), making sure that the
dependencies are still satisfied.
- Handle source lists for updates from multiple
sources. APT should also be able to handle diverse
methods of acquiring new packages; local filesystem,
mountable CD-ROM drives, FTP accesible repositories are
some of the methods that come to mind. Also, the source
lists can be separated into categories, such as main,
contrib, non-us, non-local, non-free, my-very-own,
etc. APT should be set up to retrive the Packages
files from these multiple source lists, as well as
retrieving the packages themselves.
- Handle base of source and acquire all Packages files
underneath. (possibly select based on architecture),
this should be a simple extension of the previous
requirement.
- Handle remote installation (to be implemented maybe in a
future version, it still needs to be designed). This
would ease the burden of maintaining multiple Debian
machines on a site. In the authors opinion this is a
killer difference for the distribution, though it may be
too hard a problem to be implemented with the initial
version of APT. However, some thought must be given to
this to enable APT to retain hooks for future
functionality, or at least to refrain from methods that
may preclude remote activity. It is desirable that
adding remote installation not require a redesign of
APT from the ground up.
- Be scalable. Dselect worked a lot better with 400
packages, but at last count the number of packages was
around twelve hundred and climbing. This also requires
APT to pay attention to the needs of small machines
which are low on memory (though this requirement shall
diminish as we move towards bigger machines, it would
still be nice if Debian worked on all old machines where
Linux itself would work).
- Handle install immediately requests. Some packages, like
watchdog, are required to be working for the stability
of the machine itself. There are others which may be
required for the correct functioning of a production
machine, or which are mission critical
applications. APT should, in these cases, upgrade the
packages with minimal downtime; allowing these packages
to be one of potentially hundreds of packages being
upgraded concurrently may not satisfy the requirements
of the package or the site. (Watchdog, for example, if
not restarted quickly, may cause the machine to reboot
in the midst of installation, which may cause havoc on
the machine)
[back]
[Abstract]
[Copyright Notice]
[Contents]
[next]
The APT project design document
$Id: design.sgml,v 1.1 1998/07/02 02:58:12 jgg Exp $
Manoj Srivastava srivasta@debian.org