Many people who run Linux don't want to be system administrators. That's perfectly fine; most people just want to use their computer, rather than tinker with it. However, whether you get your kicks out of system administration or not, package management is a topic that you should be familiar with. For Debian users, that means being acquainted with the dpkg system and its associated front ends.
Debian's fundamental package manager is dpkg-deb, written by Ian Jackson (the 2nd half of debIAN). However, we don't actually use dpkg-deb directly. Instead, we use a suite of tools built on top of dpkg-deb, including dpkg, dselect, apt-get and many others.
A package name is different from a package's filename. A package name is the name of the thing you're installing like "vim" or "libc6" or "prboom". The package's filename is the name of the .deb file that provides that package, like "vim_6.1.048-1_i386.deb", "libc6_2.3.1-16_i386.deb" or "prboom_2.2.3-1_i386.deb". Got it? Debian package names use lower case letters (a-z), numbers (0-9) and the three characters plus (+), minus (-) and period (.). Debian package filenames are wonderfully standardized and follow the format: packagename_version-debversion_arch.deb. Where:
- packagename: The name of the package, like "vim" "libc6".
- version: The version number of the package, assigned by the person who wrote the software. This person is known as the "upstream author" in Debian parlance.
- debversion: Sometimes a Debian package will get repackaged, even if a new version of the software hasn't been released yet. This is mainly to fix bugs or include a security update. Since there can be many releases of the same piece of software, Debian keeps a "Debian version number". When a package is repackaged without a change in the upstream source code, the debian package number gets increased.
- arch: the architecture the package is for, like "i386" or "ppc".
For example, from the Apache package filename "apache_1.3.14-1_i386.deb" you know that the package name is "apache", the upstream version is "1.3.14", the Debian version number is "1" and this particular package was compiled for the x86 platform.
The upstream authors who aren't Debian maintainers themselves probably don't know or even care about the Debian version number. This number is only of interest to the Debian maintainer for that package and the people who use that package. As an example, I have the package "apple2" on my system. From the file /usr/share/doc/apple2/changelog.Debian on my system right now:
apple2 (0.7.4-2) frozen unstable; urgency=low * Fixed symlink problem (Closes: #121271, #117805) * Fixed typo in description (Closes: #124412, #125516) -- Tom Lear <tom@MAPStrap.mtview.ca.us> Mon, 17 Dec 2001 18:59:30 -0800 apple2 (0.7.4-1) frozen unstable; urgency=low * New upstream (Closes: #82243, #83901) -- Tom Lear <tom@MAPStrap.mtview.ca.us> Wed, 4 Apr 2001 01:44:37 -0700you can see that version 0.7.4 was released as two different Debian packages. The first release (0.7.4-1) was due to the upstream author releasing a new version (0.7.4). The second Debian release (0.7.4-2) was due to a typo in the documentation and a symlink problem.
Every package installed on your system has a state. The possible states are:
- installed: The package is unpacked, installed and configured.
- not-installed: The package isn't installed on your system.
- unpacked: The package is unpacked, but not configured.
- half-installed: The installation of the package has been started, but for some reason, not finished.
- half-configured: The package is unpacked and configuration has been started, but for whatever reason, not finished.
- config-files: Only the configuration files of the package exist on the system. Normally, when you install a package and then remove it, the configuration files are left on the system. This is done so if you ever install the package again, all the config files that you tweaked will still be available. To get rid of the package and the config files, you need to purge the package, rather than uninstall the package.
There are three types of dependencies with Debian packages:
- Depends: The package depends on another package being installed first; it would make no sense for the package to be installed without the dependency package being installed. For example, Apache requires that the standard C library (glibc) be on the system. Therefore, the Apache package lists the libc package as a dependency.
- Suggests: The package suggests that another package be installed. If you install it without the suggestion, it'll still work. However, either some non-critical functionality or additional resource will be lost unless you install the suggested package. You can install the suggested package either before or after the package, it doesn't matter. For example, the Apache package suggests that you install the apache-doc package. You can certainly run Apache without the documentation installed on your system. Things would be just nicer if the documentation was there if you needed it. That's why apache-doc is listed as a suggestion, not as a dependency.
- Conflicts: The package conflicts with some other package. There could be a whole bunch of reasons for this. Often, it simply doesn't make any sense for both packages to exist on the same system. For instance, there are two unzip packages: unzip and unzip-crypt. It makes no sense for both packages to exist on the same system since they both provide the same program -- unzip. The only difference is that one version of unzip contains crypto support and the other doesn't. You should be able to see that if package A lists package B as a conflict, then by symmetry, package B will also list package A as a conflict.
There are packages like mail-transport-agent and www-browser which are called virtual packages. They describe functions that a package performs, but don't actually provide files. Why?Suppose you want to install something that works with a web browser, like Zope. It doesn't matter if you use Netscape, Opera, Amanda or Mozilla; just as long as you install some graphical browser. Therefore, Zope has a dependency on a browser. But which browser? A dependency must name another package that is required to work with Zope. We don't want to require Zope users to use a specific browser; they should use whatever browser they wish.
The answer is to have a virtual package named "graphical-www-browser", which all graphical browsers (Opera, Netscape, Mozilla, etc) provide. Then make Zope dependent on the graphical-www-browser package. This way, you can make sure that someone who uses Zope must have a graphical browser without requiring them to install a specific browser.
| Prev: Table Of Contents |
Up: Peter's Debian Notes |
Next: dpkg |
Mail corrections, suggestions and kudos to: p@dirac.org