DebianPackageManagement

From HerzbubeWiki

Jump to: navigation, search

Contents

Releases and packages

Overview

The 3 releases, or distributions, of Debian that are commonly used are:

stable 
At the time of writing, this release is named "sarge" and carries the version number v3.1r0
testing 
At the time of writing, this release is named "etch"; in time it will become the new stable release
unstable 
This release is always named "sid"; packages migrate from here into testing


In addition, there are also the following distributions:

oldstable 
This refers to the distribution just from before stable; at the time of writing, this would be "woody"
experimental 
This distribution is used for packages which are still being developed, and with a high risk of breaking your system. Note that this is not a complete distribution and therefore needs to be used in conjunction with "stable", "testing" or "unstable"


A release can also have sub-sections:

updates 
Security updates
volatile 
Packages that aim at fast moving targets, such as spam filtering and virus scanning; Updating volatile packages of a release should be absolutely painless as those package updates do not normally contain any functional changes
volatile-sloppy 
Same as volatile, but for package updates that may include functional changes or might be otherwise painful


Also see


Using the packages from a release

In order to use the packages from a certain release, this file needs to be edited:

/etc/apt/sources.list

Every line in this file contains a pointer to a package tree within a release. There are 2 different kinds of package trees:

  • binary package tree; this kind is referenced by the prefix "deb"
  • source package tree; this kind is referenced by the prefix "deb-src"

Package trees can be accessed differently:

  • on a CD-ROM; this location is referenced by the prefix "cdrom"
  • via http; this is referenced by the prefix "http://"
  • via ftp; this is referenced by the prefix "ftp://"
  • see "man sources.list" for more types

To select a specific Debian release, it must be specified either using a symbolic name (e.g. "stable", "oldstable", "testing", "unstable"), or a concrete release name (e.g. "woody", "sarge", "etch", "lenny", "squeeze").

The release name is then followed by a list of "components":

  • component is one of "main", "contrib", "non-free" or "non-us"
  • it may also be something like "non-us/main"

Examples:

deb cdrom:[Debian GNU/Linux 3.0 r1 _Woody_ - Official i386 Binary-7 (20021218)]/ unstable contrib main non-US/contrib non-US/main
deb-src http://non-us.debian.org/debian-non-US stable/non-US main contrib non-free
deb http://ftp.de.debian.org/debian/ testing main non-free contrib


Important notes:

  • Changing from one distribution to another usually is a one-way process: You can go from "stable" to "testing" to "unstable", but the reverse direction is not easily possible. This means that when the distribution is changed, no new lines need to be added to /etc/apt/sources.list - instead the lines that refer to the old distribution need to be changed so that they now point to the new distribution
  • By using a concrete release name (e.g. "etch") you make sure that your system stays at a well-known release, whereas using a symbolic name (e.g. "stable") is a moving target which may be useful if you want your system to automatically upgrade when a new Debian release is made
  • Security updates are offered for "stable" and "testing", so if you are running "unstable" or "experimental", make sure that you remove the lines relating to security updates in /etc/apt/sources.list
  • The experimental distribution is not a complete distribution and must therefore be used in conjunction with one of the full releases (probably testing or unstable, as experimental packages will usually have dependencies that are not satisfied by stable)
  • The volatile distribution usually only makes sense together with the stable distribution; see http://www.debian.org/volatile/ for details


Modifying /etc/apt/sources.list

The file can be modified manually. For adding a CD-ROM, there is the command "apt-cdrom add".

After the file has been changed, the package lists need to be updated

  • either by executing "apt-get update"
  • or by selecting "u" from within aptitude
  • or by selecting menu 2 from within dselect

If apt-get displays the error "Dynamic MMap ran out of room", the cache limit of APT must be set to a higher value. Modify the limit in the file /etc/apt/apt.conf like this (the example sets the value to 16MB):

APT::Cache-Limit 16777216;


Testing vs. unstable

There is an automatism at work that moves packages from unstable to testing after a certain amount of time. I have not yet researched how this automatism works, but I have seen a useful site that answers the question "Why is package X not in testing yet?"

http://bjorn.haxx.se/debian/testing.pl


Programs

dpkg

Basic package management operations are performed by the tool dpkg:

  • it knows how to install and uninstall .deb packages
  • it controls the package database
  • dpkg detects package dependencies and conflicts, but it does not know how to resolve them
  • dpkg is a command line utility


apt-get / apt-cache

apt-get is a more advanced tool than dpkg - it uses dpkg - it detects package dependencies and conflicts and knows how to resolve most of these problems

  • apt-get is a command line utility

apt-cache can be used to search and manipulate the APT package cache. It is also a command line utility.


For more information about APT, see http://www.debian.org/doc/manuals/apt-howto/index.en.html


dselect

dselect is a menu-driven front-end for dpkg

  • it is console based
  • it is not very user friendly, let alone intuitive
  • dselect often has problems resolving package dependencies and conflicts; it is easily possible to get into a situation that can only be resolved by using apt-get on the command line
  • I strongly recommend using aptitude over dselect
  • unfortunately, some official Debian docs (notably the APT HOWTO) mention dselect but not aptitude


aptitude

aptitude is a menu-driven front-end for APT

  • it is console based
  • it is quite intuitive and user-friendly (it even has an undo feature)
  • it is extremely clever when it comes to resolving package dependencies and conflicts


synaptic (GUI)

synaptic is a GUI front-end for APT. I currently have no experience with this tool, as I do all the administration over an SSH terminal.


SecureApt

Imagine someone has managed to hack your favourite Debian mirror, and imagine further that the package you just installed via apt was an Easter egg placed on the mirror by Mr. Hacker. Not nice...!

Luckily the people from Debian have added stuff to apt that allows to check against nasty surprises such as the example above. The whole thing is called "SecureApt", or "apt-secure" respectively. You can read more about it at

http://wiki.debian.org/SecureApt

Basically, SecureApt is about using strong cryptography to construct a "chain of verification from the package that you are going to install all the way back to the provider of the package" (quote from the Debian Wiki page mentioned above).

If on your system apt-get and/or aptitude complain about a package being "from an untrusted source", you have already encountered SecureApt - or better the lack thereof.

What you will have to do to enable SecureApt is this: For every apt repository listed in your /etc/apt/sources.list you have to add an up-to-date GPG key to a keyring that is stored in /etc/apt/trusted.gpg. The key is used by apt to check if the central "Release" file of an apt repository comes from a trusted source.

To add a key to the keyring, use one of the following commands:

apt-key add /path/to/key/file
apt-key advanced --keyserver subkeys.pgp.net --recv-keys <key ID>

You can download the current key file for official Debian archives from (replace year with current year)

http://ftp-master.debian.org/ziyi_key_2006.asc

Note that the official Debian archives key rotates every year in January, so you will have to update at least once every year. For convenience, you can install the package "debian-archive-keyring" which contains the current keys. If you update the package somewhen around January, the most up-to-date keys will automatically be imported.


dpkg

Useful commands

To install a package:

dpkg -i <path-to-deb-file>


To list the contents of a package:

dpkg --content <path-to-deb-file>
dpkg -L <package-name>


To extract (but not install) the contents of a package:

dpkg --extract <path-to-deb-file> <path-to-target-directory>


To find out which installed package provides a certain file on your system:

dpkg -S <path-to-file>


To re-display the configuration questions that were asked when a package was installed for the first time:

dpkg-reconfigure <package-name>


stat override

If you want to remove a package but dpkg does not let you, and instead displays an error message that looks like this

An override for "/path/to/file" already exists, aborting

This means that dpkg somewhere in the depths of its package database has recorded a so-called "stat override" for the mentioned file.

A "stat override" for a file (or a directory, or for any other filesystem object) is the instruction to dpkg that it should apply a specific set of owner, group and permissions to the file when it is installed. This specific set overrides (hence the name) the owner, group and permissions that are stored for the file within it's .deb file.

To list all existing "stat overrides":

dpkg-statoverride --list

To remove a "stat override" (the solution for the problem above where you are prevented from removing a package):

dpkg-statoverride --remove /path/to/file


Note: I encountered the "stat override" problem when I tried to remove the midentd package.


apt-get

Information about APT can be found at http://www.debian.org/doc/manuals/apt-howto/

.deb Files that apt-get downloads are stored for later use in /var/cache/apt/archives. It is also possible to manually download a .deb file from packages.debian.org (use the i386 architecture), put it into /var/cache/apt/archives, and then install it via apt-get.

To install a package:

apt-get install <packagename>

To remove a package (but leave config files on the system):

apt-get remove <packagename>

To completely remove a package, including all config files:

apt-get --purge remove <packagename>

To upgrade all installed packages to the newest available version (without installing new packages):

apt-get update
apt-get --show-upgraded upgrade

Ditto, but allow new packages to be installed:

apt-get update
apt-get --show-upgraded dist-upgrade


Creating a package from source

From the man page of apt-get: "source packages are not tracked like binary packages, they exist only in the current directory and are similar to downloading source tar balls."

Usually, the first step is to create a folder in which you want to build your package. cd into that directory, then execute this command:

apt-get source <packagename>

Usually this will download 3 files: the original source tar ball (e.g. with extension .tar.gz), a file that contains patches (.diff.gz) and a control file (.dsc).

After the files are downloaded, apt-get automatically invokes dpkg-source, which performs a number of actions according to the control information it finds in the .dsc file. Usually this includes extracting the source tar ball and applying the patches.

If you had specified the option "-b" to apt-get, it would have automatically compiled and built your package. But now you have to do this yourself.

cd <directory-with-extracted-sources>
dpkg-buildpackage -rfakeroot -uc -b
  • "-b" tells dpkg-buildpackage to only build the binary package (not the source package).
  • "-uc" tells dpkg-buildpackage not to sign the .changes File with a GPG key
  • "-rfakeroot" tells dpkg-buildpackage to try to gain root privileges through fakeroot; of course you can omit this if you are already root

Before launching dpkg-buildpackage you may wish to make changes that affect the outcome of the build. Go to the "debian" sub-directory inside the "extracted-sources" directory and update the necessary files; for instance, debian/rules contains the options that are passed to configure.

The product of dpkg-buildpackage is a .deb package file which you can install with "dpkg -i".


Re-packaging a binary package

If the installation process of a package is broken, it may be useful to fix the issue by yourself instead of waiting for the package maintainer to release a fixed package version. These are the commands to extract the content of a package, and to re-package the edited content into a custom package so that installation can proceed from there:

dpkg --extract /var/cache/apt/archives/bugzilla3_3.4.7.0-2_all.deb /tmp/bugzilla3_mine
dpkg --control /var/cache/apt/archives/bugzilla3_3.4.7.0-2_all.deb /tmp/bugzilla3_mine/DEBIAN
# edit some files
dpkg --build /tmp/bugzilla3_mine /tmp/bugzilla3_mine.deb
dpkg --install /tmp/bugzilla3_mine.deb

Also see Debian New Maintainer's Guide.


Bug tracker

Report a new bug

To report a new bug, either use the reportbug utility on the command line of the Debian system (recommended by Debian), or send an email to the Debian bugtracker (preferred by me). Everything is explained in detail here:

http://www.debian.org/Bugs/Reporting

Procedure:

  • send an email to submit@bugs.debian.org
  • the subject of the message will be used as the title of the bug
  • the body of the message must begin with a couple of "pseudo-headers" that tell the bugtracker which package the bug report refers to; example
Package: lprng
Version: 3.8.28dfsg.1-1.1
  • the rest of the body (possibly separated by an empty line from the pseudo-headers) contains the actual bug report


Reply/add comment to an existing bug

For instance, to reply or add a comment to bug report 12345:

  • send an email to 12345@bugs.debian.org


Watch an existing bug

The following page details how to "watch" an existing bug report for changes:

http://www.debian.org/Bugs/Developer#subscribe

For instance, to watch bug 12345:

  • send an email to 12345-subscribe@bugs.debian.org; subject and body are ignored, so should be empty
  • wait for the confirmation message sent back by the bugtracker
  • reply to the confirmation message to prove that you own the subscribing email adress

Unsubscribing works along the same principle, just send an email to 12345-unsubscribe@bugs.debian.org.


popularity-contest

The package popularity-contest collects statistics about which packages are installed on a system, how these packages are updated and used. The software "phones home" once in a while (weekly at the time I installed it) to submit the collected statistical data to the Debian servers. On the following site, global results of the survey can be viewed:

http://popcon.debian.org/

Even with an installed popcon package it is possible not to participate in the survey for some time:

dpkg-reconfigure popularity-contest


Removing unused packages

deborphan

From the Manual

From the man page of deborphan:

deborphan - Orphaned package finder

deborphan finds packages that have no packages depending on them. The default operation is to search only within the libs and oldlibs sections to hunt down unused libraries.


Overview

deborphan helps to find orphaned packages, i.e. packages that have no packages depending on them. deborphan operates on the dpkg/apt package database. Candidate packages need to be removed manually, which makes deborphan safe and simple to use. On the other hand, deborphan does not tell you anything about why a package is orphaned.


Usage

As the man page explains, simply running deborphan without any options searches for orphaned packages only within the libs and oldlibs sections. This is usually OK since libraries are mostly installed only as a dependency to other packages, hence an orphaned library is usually one of those accidental orphans that we actually want to find.

To include a couple more libraries (in section libdevel):

deborphan --libdevel

For a comprehensive search that includes really all packages (not only from all sections, but also with all priorities):

deborphan --all-packages --priority=1 --show-priority

This kind of search will produce a list that is much too large because it includes all those packages you have explicitly installed by intent. To exclude those packages:

deborphan --all-packages --priority=1 --show-priority --exclude=foo,bar[,...]

deborphan is capable of maintaining a so-called keep file; this is a file that permanently stores package names that you would otherwise specify with --exclude. To add/remove packages to/from the keep file, or to list the content of the keep file:

deborphan --add-keep foo bar
deborphan --del-keep foo bar
deborphan --list-keep

The default keep file is /var/lib/deborphan/keep. It will be taken into account whenever you run deborphan. If you want to maintain/use a different keep file, simply add the --keep-file=my.keep.file.


Aggressive usage

An aggressive search can be made by adding the --nice-mode option. A little bit counter-intuititve, this option turns nice-mode off. Nice-mode (which is turned on by default) means that a package is not considered an orphan if another package suggests or recommends it. If nice-mode is turned off, only hard dependencies will prevent a package from becoming an orphan.

Another method to treat more packages as orphans is the --force-hold option. This lets deborphan ignore the "hold" flag present on any packages. Due to a bug in aptitude (see BTS), "hold" flags set by aptitude seem to be ignored by deborphan anyway.


Unpurged packages

Another useful operation mode is

deborphan --find-config

This finds all packages that are no longer installed but which still have configuration files on the system. Purging a package might be especially useful to remove the last trace of the package's still lingering "ghost" from the package database :-) i.e. purging the package will make it disappear completely from the package database and the package lists seen by apt/aptitude.

Note: Unpurged packages can also be found by searching in aptitude for "~c" (tilde c).


debfoster

Don't Use It!

I have stopped evaluating debfoster when the second package that it queried me about was a package installed due to a "recommends" dependency. Since the debfoster default configuration is supposed to treat recommendations as real dependencies, I conclude that debfoster is seriously broken and cannot properly evaluate dependencies!

This harsh statement is somewhat supported by http://www.fruit.je/debfoster/ where it says

As of 2006-01-01, debfoster is officially deprecated: aptitude does the same stuff as debfoster but integrated into the apt system

OTOH I found an email thread that says that debfoster is being taken over by other people. What should I believe? The package changelog seems not too encouraging, listing exactly one update since July 2006. I conclude not to waste my time with something that I can do with deborphan and aptitude.

The following stuff is kept for the moment "just in case".


From the Manual

From the man page of debfoster:

debfoster - weed unnecessary Debian packages

debfoster maintains a list of installed packages that were explicitly requested rather than installed as a dependency. [...] debfoster can be invoked per se after each run of dpkg and/or apt-get. [...] If a new package is encountered or if debfoster notices that a package that used to be a dependency is now an orphan, it will ask you what to do with it. If you decide to keep it, debfoster will just take note and continue. If you decide that this package is not interesting enough it will be removed as soon as debfoster is done asking questions. If your choices cause other packages to become orphaned more questions will ensue.


Overview

debfoster examines orphaned packages more closely than deborphan. For instance, it tells you which other packages are kept installed by the orphan package, i.e. which packages would get uninstalled if you were to remove the orphan package. debfoster is usually run as an interactive program. To be useful it needs to maintain its own package database that is separate from the dpkg/apt database.


Usage

The database kept by debfoster is in this file:

/var/lib/debfoster/keepers

debfoster uses this configuration file (options in the configuration file can be overridden with the --option command line argument):

/etc/debfoster.conf

Running debfoster without options start an interactive session where the user is queried about each package that debfoster considers an orphan. The user must decide which packages should be kept and which packages can be removed.


Aggressive usage

debfoster --option MaxPriority=required
debfoster --option UseHold=no
debfoster --option UseEssential=no
debfoster --option UseRecommends=no
debfoster --option UsePreDepends=no


aptitude

An extremely useful feature of aptitude is to ask "why", such as:

osgiliath:~# aptitude why alien
i   nagios-text   Depends nagios-common (= 2:1.4-3.1)
i A nagios-common Depends lsb-core                   
i A lsb-core      Depends alien (>= 8.36)            
Personal tools
francesca