Here are some key points for package configuration on the Debian system.

The newbie Debian system administrator should stay with the stable release of Debian while applying only security updates. I mean that some of the following valid actions are better avoided, as a precaution, until you understand the Debian system very well. Here are some reminders.

The non-compatible effects caused by above actions to the Debian package management system may leave your system unusable.

The serious Debian system administrator who runs mission critical servers, should use extra precautions.

Despite my warnings above, I know many readers of this document wish to run the testing or unstable suites of Debian as their main system for self-administered Desktop environments. This is because they work very well, are updated frequently, and offer the latest features.

It takes no more than simply setting the distribution string in the "/etc/apt/sources.list" to the suite name: "testing" or "unstable"; or the codename: "squeeze" or "sid". This makes you live the life of eternal upgrades.

The use of testing or unstable is a lot of fun but comes with some risks. Even though the unstable suite of Debian system looks very stable for most of the times, there have been some package problems on the testing and unstable suite of Debian system and a few of them were not so trivial to resolve. It may be quite painful for you. Sometimes, you may have a broken package or missing functionality for a few weeks.

Here are some ideas to ensure quick and easy recovery from bugs in Debian packages.

(If you can not do any one of these precautionary actions, you are probably not ready for the testing and unstable suites.)

Enlightenment with the following saves a person from the eternal karmic struggle of upgrade hell and let him reach Debian nirvana.

Let's look into the Debian archive from a system user's perspective.

For the typical HTTP access, the archive is specified in the "/etc/apt/sources.list" file as the following, e.g. for the current stable = lenny system.

deb http://ftp.XX.debian.org/debian/ lenny main contrib non-free
deb-src http://ftp.XX.debian.org/debian/ lenny main contrib non-free

deb http://security.debian.org/ lenny/updates main contrib
deb-src http://security.debian.org/ lenny/updates main contrib

Please note "ftp.XX.debian.org" must be replaced with appropriate mirror site URL for your location, for USA "ftp.us.debian.org", which can be found in the list of Debian worldwide mirror sites. The status of these servers can be checked at Debian Mirror Checker site.

Here, I tend to use codename "lenny" instead of suite name "stable" to avoid surprises when the next stable is released.

The meaning of "/etc/apt/sources.list" is described in sources.list(5) and key points are followings.

The "deb-src" lines can safely be omitted (or commented out by placing "#" at the start of the line) if it is just for aptitude which does not access source related meta data. It speeds up the updates of the archive meta data. The URL can be "http://", "ftp://", "file://", ….

Here is the list of URL of the Debian archive sites and suite name or codename used in the configuration file.

Each Debian archive consists of 3 components. Components are alternatively called categories in "Debian Policy" or areas in "Debian Social Contract". The component is grouped by the compliance to "The Debian Free Software Guidelines" (DFSG).

Here the number of packages in the above is for the amd64 architecture. Strictly speaking, only the main component archive shall be considered as the Debian system.

The Debian archive organization can be studied best by pointing your browser to the each archive URL appended with dists or pool.

The distribution is referred by two ways, the suite or codename. The word distribution is alternatively used as the synonym to the suite in many documentations. The relationship between the suite and the codename can be summarized as the following.

The history of codenames are described in Debian FAQ: 6.3.1 Which other codenames have been used in the past?

In the stricter Debian archive terminology, the word "section" is specifically used for the categorization of packages by the application area. (Although, the word "main section" may sometimes be used to describe the Debian archive section which provides the main component.)

Every time a new upload is done by the Debian developer (DD) to the unstable archive (via incoming processing), DD is required to ensure uploaded packages to be compatible with the latest set of packages in the latest unstable archive.

If DD breaks this compatibility intentionally for important library upgrade etc, there is usually announcement to the debian-devel mailing list etc.

Before a set of packages are moved by the Debian archive maintenance script from the unstable archive to the testing archive, the archive maintenance script not only checks the maturity (about 10 days old) and the status of the RC bug reports for the packages but also tries to ensure them to be compatible with the latest set of packages in the testing archive. This process makes the testing archive very current and usable.

Through the gradual archive freeze process led by the release team, the testing archive is matured to make it completely consistent and bug free with some manual interventions. Then the new stable release is created by assigning the codename for the old testing archive to the new stable archive and creating the new codename for the new testing archive. The initial contents of the new testing archive is exactly the same as that of the newly released stable archive.

Both the unstable and the testing archives may suffer temporary glitches due to several factors.

So if you ever decide to use these archives, you should be able to fix or work around these kinds of glitches.

See Debian Policy Manual for archive definitions.

The Debian system offers a consistent set of binary packages through its versioned binary dependency declaration mechanism in the control file fields. Here is a bit over simplified definition for them.

The official definition including source dependency can be found in the Policy Manual: Chapter 7 - Declaring relationships between packages.

Here is a summary of the simplified event flow of the package management by APT.

Here, I intentionally skipped technical details for the sake of big picture.

You should read the fine official documentation. The first document to read is the Debian specific "/usr/share/doc/<package_name>/README.Debian". Other documentation in "/usr/share/doc/<package_name>/" should be consulted too. If you set shell as Sección 1.4.2, “Customizing bash”, type the following.

$ cd <package_name>
$ pager README.Debian
$ mc

You may need to install the corresponding documentation package named with "-doc" suffix for detailed information.

If you are experiencing problems with a specific package, make sure to check out the Debian bug tracking system (BTS) sites, first.

Search Google with search words including "site:debian.org", "site:wiki.debian.org", "site:lists.debian.org", etc.

When you file a bug report, please use reportbug(1) command.

Here are basic package management operations with commandline using aptitude(8) and apt-get(8) /apt-cache(8).

Although it is now safe to mix different package tools on the Debian system, it is best to continue using aptitude as much as possible.

The difference between "safe-upgrade"/"upgrade" and "full-upgrade"/"dist-upgrade" only appears when new versions of packages stand in different dependency relationships from old versions of those packages. The "aptitude safe-upgrade" command does not install new packages nor remove installed packages.

The "aptitude why <regex>" can list more information by "aptitude -v why <regex>". Similar information can be obtained by "apt-cache rdepends <package>".

When aptitude command is started in the commandline mode and faces some issues such as package conflicts, you can switch to the full screen interactive mode by pressing "e"-key later at the prompt.

You may provide command options right after "aptitude".

See aptitude(8) and "aptitude user's manual" at "/usr/share/doc/aptitude/README" for more.

For the interactive package management, you start aptitude in interactive mode from the console shell prompt as follows.

$ sudo aptitude -u
Password:

This updates the local copy of the archive information and display the package list in the full screen with menu. Aptitude places its configuration at "~/.aptitude/config".

Notable key strokes to browse status of packages and to set "planned action" on them in this full screen mode are the following.

The file name specification of the command line and the menu prompt after pressing "l" and "//" take the aptitude regex as described below. Aptitude regex can explicitly match a package name using a string started by "~n and followed by the package name.

In the interactive full screen mode of aptitude(8), packages in the package list are displayed as the next example.

idA   libsmbclient                             -2220kB 3.0.25a-1  3.0.25a-2

Here, this line means from the left as the following.

The candidate version is chosen according to the current local preferences (see apt_preferences(5) and Sección 2.7.3, “Tweaking candidate version”).

Several types of package views are available under the menu "Views".

The standard "Package View" categorizes packages somewhat like dselect with few extra features.

Aptitude offers several options for you to search packages using its regex formula.

The aptitude regex formula is mutt-like extended ERE (see Sección 1.6.2, “Regular expressions”) and the meanings of the aptitude specific special match rule extensions are as follows.

Here are some short cuts.

Users familiar with mutt pick up quickly, as mutt was the inspiration for the expression syntax. See "SEARCHING, LIMITING, AND EXPRESSIONS" in the "User's Manual" "/usr/share/doc/aptitude/README".

The selection of a package in aptitude not only pulls in packages which are defined in its "Depends:" list but also defined in the "Recommends:" list if the menu "F10 → Options → Dependency handling" is set accordingly. These auto installed packages are removed automatically if they are no longer needed under aptitude.

You can check package activity history in the log files.

In reality, it is not so easy to get meaningful understanding quickly out from these logs. See Sección 9.2.9, “Recording changes in configuration files” for easier way.

Aptitude has advantages over other APT based packaging systems (apt-get, apt-cache, synaptic, …).

For the old etch release version, synaptic also gives you the history log; apt-get did not but you can rely on the log of dpkg.

Anyway, aptitude is nice for interactive console use.

The following command lists packages with regex matching on package names.

$ aptitude search '~n(pam|nss).*ldap'
p libnss-ldap - NSS module for using LDAP as a naming service
p libpam-ldap - Pluggable Authentication Module allowing LDAP interfaces

This is quite handy for you to find the exact name of a package.

The regex "~dipv6" in the "New Flat Package List" view with "l" prompt, limits view to packages with the matching description and let you browse their information interactively.

You can purge all remaining configuration files of removed packages.

Check results of the following command.

# aptitude search '~c'

If you think listed packages are OK to be purged, execute the following command.

# aptitude purge '~c'

You may want to do the similar in the interactive mode for fine grained control.

You provide the regex "~c" in the "New Flat Package List" view with "l" prompt. This limits the package view only to regex matched packages, i.e., "removed but not purged". All these regex matched packages can be shown by pressing "[" at top level headings.

Then you press "_" at top level headings such as "Installed Packages". Only regex matched packages under the heading are marked to be purged by this. You can exclude some packages to be purged by pressing "=" interactively for each of them.

This technique is quite handy and works for many other command keys.

Here is how I tidy auto/manual install status for packages (after using non-aptitude package installer etc.).

The "m" action over "Tasks" is an optional one to prevent mass package removal situation in future.

You can perform system wide upgrade to a newer release by changing contents of the "/etc/apt/sources.list" file pointing to a new release and running the "aptitude update; aptitude full-upgrade" command.

To upgrade from stable to testing or unstable, you replace "lenny" in the "/etc/apt/sources.list" example of Sección 2.1.4, “Debian archive basics” with "squeeze" or "sid".

In reality, you may face some complications due to some package transition issues, mostly due to package dependencies. The larger the difference of the upgrade, the more likely you face larger troubles. For the transition from the old stable to the new stable after its release, you can read its new Release Notes and follow the exact procedure described in it to minimize troubles.

When you decide to move from stable to testing before its formal release, there are no Release Notes to help you. The difference between stable and testing could have grown quite large after the previous stable release and makes upgrade situation complicated.

You should make precautionary moves for the full upgrade while gathering latest information from mailing list and using common senses.

For daily upgrade in unstable, see Sección 2.4.3, “Safeguarding for package problems”.

Here are list of other package management operations for which aptitude is too high-level or lacks required functionalities.

Please note the following.

The installation of debsums enables verification of installed package files against MD5sum values in the "/var/lib/dpkg/info/*.md5sums" file with debsums(1). See Sección 10.3.5, “The MD5 sum” for how MD5sum works.

Many users prefer to follow the unstable release of the Debian system for its new features and packages. This makes the system more prone to be hit by the critical package bugs.

The installation of the apt-listbugs package safeguards your system against critical bugs by checking Debian BTS automatically for critical bugs when upgrading with APT system.

The installation of the apt-listchanges package provides important news in "NEWS.Debian" when upgrading with APT system.

Although visiting Debian site http://packages.debian.org/ facilitates easy ways to search on the package meta data these days, let's look into more traditional ways.

The grep-dctrl(1), grep-status(1), and grep-available(1) commands can be used to search any file which has the general format of a Debian package control file.

The "dpkg -S <file_name_pattern>" can be used search package names which contain files with the matching name installed by dpkg. But this overlooks files created by the maintainer scripts.

If you need to make more elaborate search on the dpkg meta data, you need to run "grep -e regex_pattern *" command in the "/var/lib/dpkg/info/" directory. This makes you search words mentioned in package scripts and installation query texts.

If you wish to look up package dependency recursively, you should use apt-rdepends(8).

Meta data files for each distribution are stored under "dist/<codename>" on each Debian mirror sites, e.g., "http://ftp.us.debian.org/debian/". Its archive structure can be browsed by the web browser. There are 6 types of key meta data.

In the recent archive, these meta data are stored as the compressed and differential files to reduce network traffic.

Each suite of the Debian archive has a top level "Release" file, e.g., "http://ftp.us.debian.org/debian/dists/unstable/Release", as follows.

Origin: Debian
Label: Debian
Suite: unstable
Codename: sid
Date: Sat, 26 Jan 2008 20:13:58 UTC
Architectures: alpha amd64 arm hppa hurd-i386 i386 ia64 m68k mips mipsel powerpc s390 sparc
Components: main contrib non-free
Description: Debian x.y Unstable - Not Released
MD5Sum:
 e9f11bc50b12af7927d6583de0a3bd06 22788722 main/binary-alpha/Packages
 43524d07f7fa21b10f472c426db66168  6561398 main/binary-alpha/Packages.gz
...

The integrity of the top level "Release" file is verified by cryptographic infrastructure called the secure apt.

The integrity of all the "Packages" and "Sources" files are verified by using MD5sum values in its top level "Release" file. The integrity of all package files are verified by using MD5sum values in the "Packages" and "Sources" files. See debsums(1) and Sección 2.4.2, “Verification of installed package files”.

Since the cryptographic signature verification is very CPU intensive process than the MD5sum value calculation, use of MD5sum value for each package while using cryptographic signature for the top level "Release" file provides the good security with the performance (see Sección 10.3, “Data security infrastructure”).

There are archive level "Release" files for all archive locations specified by "deb" line in "/etc/apt/sources.list", such as "http://ftp.us.debian.org/debian/dists/unstable/main/binary-amd64/Release" or "http://ftp.us.debian.org/debian/dists/sid/main/binary-amd64/Release" as follows.

Archive: unstable
Component: main
Origin: Debian
Label: Debian
Architecture: amd64

For some archives, such as experimental, volatile-sloppy, and lenny-backports, which contain packages which should not be installed automatically, there is an extra line, e.g., "http://ftp.us.debian.org/debian/dists/experimental/main/binary-amd64/Release" as follows.

Archive: experimental
Component: main
Origin: Debian
Label: Debian
NotAutomatic: yes
Architecture: amd64

Please note that for normal archives without "NotAutomatic: yes", the default Pin-Priority value is 500, while for special archives with "NotAutomatic: yes", the default Pin-Priority value is 1 (see apt_preferences(5) and Sección 2.7.3, “Tweaking candidate version”).

When APT tools, such as aptitude, apt-get, synaptic, apt-file, auto-apt…, are used, we need to update the local copies of the meta data containing the Debian archive information. These local copies have following file names corresponding to the specified distribution, component, and architecture names in the "/etc/apt/sources.list" (see Sección 2.1.4, “Debian archive basics”).

First 4 types of files are shared by all the pertinent APT commands and updated from command line by "apt-get update" and "aptitude update". The "Packages" meta data are updated if there is the "deb" line in "/etc/apt/sources.list". The "Sources" meta data are updated if there is the "deb-src" line in "/etc/apt/sources.list".

The "Packages" and "Sources" meta data contain "Filename:" stanza pointing to the file location of the binary and source packages. Currently, these packages are located under the "pool/" directory tree for the improved transition over the releases.

Local copies of "Packages" meta data can be interactively searched with the help of aptitude. The specialized search command grep-dctrl(1) can search local copies of "Packages" and "Sources" meta data.

Local copy of "Contents-<architecture>" meta data can be updated by "apt-file update" and its location is different from other 4 ones. See apt-file(1). (The auto-apt uses different location for local copy of "Contents-<architecture>.gz" as default.)

In addition to the remotely fetched meta data, the APT tool after lenny stores its locally generated installation state information in the "/var/lib/apt/extended_states" which is used by all APT tools to track all auto installed packages.

In addition to the remotely fetched meta data, the aptitude command stores its locally generated installation state information in the "/var/lib/aptitude/pkgstates" which is used only by it.

All the remotely fetched packages via APT mechanism are stored in the "/var/cache/apt/packages" until they are cleaned.

Debian package files have particular name structures.

dpkg(1) is the lowest level tool for the Debian package management. This is very powerful and needs to be used with care.

While installing package called "<package_name>", dpkg process it in the following order.

The debconf system provides standardized user interaction with I18N and L10N (Capítulo 8, I18N and L10N) supports.

The "status" file is also used by the tools such as dpkg(1), "dselect update" and "apt-get -u dselect-upgrade".

The specialized search command grep-dctrl(1) can search the local copies of "status" and "available" meta data.

The Debian system has mechanism to install somewhat overlapping programs peacefully using update-alternatives(8). For example, you can make the vi command select to run vim while installing both vim and nvi packages.

$ ls -l $(type -p vi)
lrwxrwxrwx 1 root root 20 2007-03-24 19:05 /usr/bin/vi -> /etc/alternatives/vi
$ sudo update-alternatives --display vi
...
$ sudo update-alternatives --config vi
  Selection    Command
 ----------------------------------------------
      1        /usr/bin/vim
*+    2        /usr/bin/nvi

Enter to keep the default[*], or type selection number: 1

The Debian alternatives system keeps its selection as symlinks in "/etc/alternatives/". The selection process uses corresponding file in "/var/lib/dpkg/alternatives/".

Stat overrides provided by the dpkg-statoverride(8) command are a way to tell dpkg(1) to use a different owner or mode for a file when a package is installed. If "--update" is specified and file exists, it is immediately set to the new owner and mode.

File diversions provided by the dpkg-divert(8) command are a way of forcing dpkg(1) not to install a file into its default location, but to a diverted location. The use of dpkg-divert is meant for the package maintenance scripts. Its casual use by the system administrator is deprecated.

If a desktop GUI program experienced instability after significant upstream version upgrade, you should suspect interferences with old local configuration files created by it. If it is stable under newly created user account, this hypothesis is confirmed. (This is a bug of packaging and usually avoided by the packager.)

To recover stability, you should move corresponding local configuration files and restart the GUI program. You may need to read old configuration file contents to recover configuration information later. (Do not erase them too quickly.)

Archive level package management systems, such as aptitude(8) or apt-get(1), do not even try to install packages with overlapped files using package dependencies (see Sección 2.1.5, “Package dependencies”).

Errors by the package maintainer or deployment of inconsistently mixed source of archives (see Sección 2.7.2, “Packages from mixed source of archives”) by the system administrator may create situation with incorrectly defined package dependencies. When you install a package with overlapped files using aptitude(8) or apt-get(1) under such situation, dpkg(1) which unpacks package ensures to return error to the calling program without overwriting existing files.

You can work around such broken installation by removing the old offending package, <old-package>, first.

$ sudo dpkg -P <old-package>

When a command in the package script returns error for some reason and the script exits with error, the package management system aborts their action and ends up with partially installed packages. When a package contains bugs in its removal scripts, the package may become impossible to remove and quite nasty.

For the package script problem of "<package_name>", you should look into following package scripts.

Edit the offending package script from the root using following techniques.

Configure all partially installed packages with the following command.

# dpkg --configure -a

Since dpkg is very low level package tool, it can function under the very bad situation such as unbootable system without network connection. Let's assume foo package was broken and needs to be replaced.

You may still find cached copies of older bug free version of foo package in the package cache directory: "/var/cache/apt/archives/". (If not, you can download it from archive of http://snapshot.debian.net/ or copy it from package cache of a functioning machine.)

If you can boot the system, you may install it by the following command.

# dpkg -i /path/to/foo_<old_version>_<arch>.deb

If your system is unbootable from hard disk, you should seek other ways to boot it.

# dpkg --root /target -i /path/to/foo_<old_version>_<arch>.deb

This example works even if the dpkg command on the hard disk is broken.

If attempting to install a package this way fails due to some dependency violations and you really need to do this as the last resort, you can override dependency using dpkg's "--ignore-depends", "--force-depends" and other options. If you do this, you need to make serious effort to restore proper dependency later. See dpkg(8) for details.

If "/var/lib/dpkg/status" becomes corrupt for any reason, the Debian system loses package selection data and suffers severely. Look for the old "/var/lib/dpkg/status" file at "/var/lib/dpkg/status-old" or "/var/backups/dpkg.status.*".

Keeping "/var/backups/" in a separate partition may be a good idea since this directory contains lots of important system data.

For serious breakage, I recommend to make fresh re-install after making backup of the system. Even if everything in "/var/" is gone, you can still recover some information from directories in "/usr/share/doc/" to guide your new installation.

Reinstall minimal (desktop) system.

# mkdir -p /path/to/old/system

Mount old system at "/path/to/old/system/".

# cd /path/to/old/system/usr/share/doc
# ls -1 >~/ls1.txt
# cd /usr/share/doc
# ls -1 >>~/ls1.txt
# cd
# sort ls1.txt | uniq | less

Then you are presented with package names to install. (There may be some non-package names such as "texmf".)

You can seek packages which satisfy your needs with aptitude from the package description or from the list under "Tasks".

When you encounter more than 2 similar packages and wonder which one to install without "trial and error" efforts, you should use some common sense. I consider following points are good indications of preferred packages.

Debian being a volunteer project with distributed development model, its archive contains many packages with different focus and quality. You must make your own decision what to do with them.

Here is an example of operations to include specific newer upstream version packages found in unstable while tracking testing for single occasion.

You do not create the "/etc/apt/preferences" file nor need to worry about apt-pinning with this manual approach. But this is very cumbersome.

General rules for installing packages from different archives are followings.

Without the "/etc/apt/preferences" file, APT system choses the latest available version as the candidate version using the version string. This is the normal state and most recommended usage of APT system. All officially supported combinations of archives do not require the "/etc/apt/preferences" file since some archives which should not be used as the automatic source of upgrades are marked as NotAutomatic and dealt properly.

When you install packages from mixed source of archives (see Sección 2.7.2, “Packages from mixed source of archives”) regularly, you can automate these complicated operations by creating the "/etc/apt/preferences" file with proper entries and tweaking the package selection rule for candidate version as described in apt_preferences(5). This is called apt-pinning.

Here is a simplified explanation of apt-pinning technique.

APT system choses highest Pin-Priority upgrading package from available package sources defined in the "/etc/apt/sources.list" file as the candidate version package. If the Pin-Priority of the package is larger than 1000, this version restriction for upgrading is dropped to enable downgrading (see Sección 2.7.7, “Emergency downgrading”).

Pin-Priority value of each package is defined by "Pin-Priority" entries in the "/etc/apt/preferences" file or uses its default value.

The target release archive can be set by several methods.

The NotAutomatic archive is set by archive server having its archive level Release file (see Sección 2.5.3, “Archive level "Release" files”) containing "NotAutomatic: yes".

The apt-pinning situation of <package> from multiple archive sources is displayed by "apt-cache policy <package>".

Here is an example of apt-pinning technique to include specific newer upstream version packages found in unstable regularly upgraded while tracking testing. You list all required archives in the "/etc/apt/sources.list" file as the following.

deb http://ftp.us.debian.org/debian/ testing main contrib non-free
deb http://ftp.us.debian.org/debian/ unstable main contrib non-free
deb http://security.debian.org/ testing/updates main contrib

Set the "/etc/apt/preferences" file as as the following.

Package: *
Pin: release a=testing
Pin-Priority: 500

Package: *
Pin: release a=unstable
Pin-Priority: 200

When you wish to install a package named "<package-name>" with its dependencies from unstable archive under this configuration, you issue the following command which switches target release with "-t" option (Pin-Priority of unstable becomes 990.).

$ sudo apt-get install -t unstable <package-name>

With this configuration, usual execution of "apt-get upgrade" and "apt-get dist-upgrade" (or "aptitude safe-upgrade" and "aptitude full-upgrade" for squeeze) upgrades packages which were installed from testing archive using current testing archive and packages which were installed from unstable archive using current unstable archive.

If you wish to track particular packages in unstable automatically without initial "-t unstable" installation, you must create the "/etc/apt/preferences" file and explicitly list all those packages at the top of it as the following.

Package: <package-1>
Pin: release a=unstable
Pin-Priority: 700

Package: <package-2>
Pin: release a=unstable
Pin-Priority: 700

These set Pin-Priority value for each specific package. For example, in order to track the latest unstable version of this "Debian Reference" in English, you should have following entries in the "/etc/apt/preferences" file.

Package: debian-reference-en
Pin: release a=unstable
Pin-Priority: 700

Package: debian-reference-common
Pin: release a=unstable
Pin-Priority: 700

Here is another example of apt-pinning technique to include specific newer upstream version packages found in experimental while tracking unstable. You list all required archives in the "/etc/apt/sources.list" file as the following.

deb http://ftp.us.debian.org/debian/ unstable main contrib non-free
deb http://ftp.us.debian.org/debian/ experimental main contrib non-free
deb http://security.debian.org/ testing/updates main contrib

The default Pin-Priority value for experimental archive is always 1 (<<100) since it is NotAutomatic archive (see Sección 2.5.3, “Archive level "Release" files”). There is no need to set Pin-Priority value explicitly in the "/etc/apt/preferences" file just to use experimental archive unless you wish to track particular packages in it automatically for next upgrading.

There are debian-volatile project and backports.org archives which provide updgrade packages for stable.

Here is an example of apt-pinning technique to include specific newer upstream version packages found in lenny-backports while tracking lenny and volatile. You list all required archives in the "/etc/apt/sources.list" file as the following.

deb http://ftp.us.debian.org/debian/ lenny main contrib non-free
deb http://security.debian.org/ lenny/updates main contrib
deb http://volatile.debian.org/debian-volatile/ lenny/volatile main contrib non-free
deb http://volatile.debian.org/debian-volatile/ lenny/volatile-sloppy main contrib non-free
deb http://backports.org/debian/ lenny-backports main contrib non-free

The default Pin-Priority value for backports.org and volatile-sloppy archives are always 1 (<<100) since they are NotAutomatic archive (see Sección 2.5.3, “Archive level "Release" files”). There is no need to set Pin-Priority value explicitly in the "/etc/apt/preferences" file just to use for backports.org and volatile-sloppy archive unless you wish to track packages automatically for next upgrading.

So whenever you wish to install a package named "<package-name>" with its dependency from lenny-backports archive, you use following command while switching target release with "-t" option.

$ sudo apt-get install -t lenny-backports <package-name>

If you wish to upgrade particular packages, you must create the "/etc/apt/preferences" file and explicitly lists all packages in it as the following.

Package: <package-1>
Pin: release o=Backports.org archive
Pin-Priority: 700

Package: <package-2>
Pin: release o=volatile.debian.org
Pin-Priority: 700

Alternatively, with the "/etc/apt/preferences" file as the following.

Package: *
Pin: release a=stable , o=Debian
Pin-Priority: 500

Package: *
Pin: release a=lenny, o=volatile.debian.org
Pin-Priority: 500

Package: *
Pin: release a=lenny-backports, o=Backports.org archive
Pin-Priority: 200

Package: *
Pin: release a=lenny-sloppy, o=volatile.debian.org
Pin-Priority: 200

Execution of "apt-get upgrade" and "apt-get dist-upgrade" (or "aptitude safe-upgrade" and "aptitude full-upgrade" for squeeze) upgrades packages which were installed from stable archive using current stable archive and packages which were installed from other archives using current corresponding archive for all archives in the "/etc/apt/sources.list" file.

The apt package comes with its own cron script "/etc/cron.daily/apt" to support the automatic download of packages. This script can be enhanced to perform the automatic upgrade of packages by installing the unattended-upgrades package. These can be customized by parameters in "/etc/apt/apt.conf.d/02backup" and "/etc/apt/apt.conf.d/50unattended-upgrades" as described in "/usr/share/doc/unattended-upgrades/README".

The unattended-upgrades package is mainly intended for the security upgrade for the stable system. If the risk of breaking an existing stable system by the automatic upgrade is smaller than that of the system broken by the intruder using its security hole which has been closed by the security update, you should consider using this automatic upgrade with configuration parameters as the following.

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Unattended-Upgrade "1";

If you are running an unstable system, you do not want to use the automatic upgrade since it certainly breaks system some day. Even for such unstable case, you may still want to download packages in advance to save time for the interactive upgrade with configuration parameters as the following.

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Unattended-Upgrade "0";

If you want to limit the download bandwidth for APT to e.g. 800Kib/sec (=100kiB/sec), you should configure APT with its configuration parameter as the following.

APT::Acquire::http::Dl-Limit "800";

You may be lucky to downgrade from newer archive to older archive to recover from broken system upgrade by manipulating candidate version (see Sección 2.7.3, “Tweaking candidate version”). This is lazy alternative to tedious actions of many "dpkg -i <broken-package>_<old-version>.deb" commands (see Sección 2.6.4, “Rescue with the dpkg command”).

Search lines in the "/etc/apt/sources.list" file tracking unstable as the following.

deb http://ftp.us.debian.org/debian/ sid main contrib non-free

Replace it with the following to track testing.

deb http://ftp.us.debian.org/debian/ squeeze main contrib non-free

Set the "/etc/apt/preferences" file as the following.

Package: *
Pin: release a=testing
Pin-Priority: 1010

Run "apt-get dist-upgrade" to force downgrading of packages across the system.

Remove this special "/etc/apt/preferences" file after this emergency downgrading.

Although the maintainer name listed in "/var/lib/dpkg/available" and "/usr/share/doc/package_name/changelog" provide some information on "who is behind the packaging activity", the actual uploader of the package is somewhat obscure. who-uploads(1) in the devscripts package identifies the actual uploader of Debian source packages.

If you are to compile a program from source to replace the Debian package, it is best to make it into a real local debianized package (*.deb) and use private archive.

If you chose to compile a program from source and to install them under "/usr/local" instead, you may need to use equivs as a last resort to satisfy the missing package dependency.

Package: equivs
Priority: extra
Section: admin
Description: Circumventing Debian package dependencies
 This is a dummy package which can be used to create Debian
 packages, which only contain dependency information.

For partial upgrades of the stable system, rebuilding a package within its environment using the source package is desirable. This avoids massive package upgrades due to their dependencies.

Add the following entries to the "/etc/apt/sources.list" of a stable system.

deb-src http://http.us.debian.org/debian unstable  main contrib non-free

Install required packages for the compilation and download the source package as the following.

# apt-get update
# apt-get dist-upgrade
# apt-get install fakeroot devscripts build-essential
$ apt-get build-dep foo
$ apt-get source foo
$ cd foo*

Adjust installed packages if needed.

Execute the following.

$ dch -i

Bump package version, e.g. one appended with "+bp1" in "debian/changelog"

Build packages and install them to the system as the following.

$ debuild
$ cd ..
# debi foo*.changes

Since mirroring whole subsection of Debian archive wastes disk space and network bandwidth, deployment of a local proxy server for APT is desirable consideration when you administer many systems on LAN. APT can be configure to use generic web (http) proxy servers such as squid (see Sección 6.10, “Other network application servers”) as described in apt.conf(5) and in "/usr/share/doc/apt/examples/configure-index.gz". The "$http_proxy" environment variable can be used to override proxy server setting in the "/etc/apt/apt.conf" file.

There are proxy tools specially for Debian archive. You should check BTS before using them.

Here is an example for creating a small public package archive compatible with the modern secure APT system (see Sección 2.5.2, “Top level "Release" file and authenticity”). Let's assume few things.

Create an APT archive key of Foo on your server system as the following.

$ ssh foo@www.example.com
$ gpg --gen-key
...
$ gpg -K
...
sec   1024D/3A3CB5A6 2008-08-14
uid                  Foo (ARCHIVE KEY) <foo@www.example.com>
ssb   2048g/6856F4A7 2008-08-14
$ gpg --export -a 3A3CB5A6 >foo.public.key

Publish the archive key file "foo.public.key" with the key ID "3A3CB5A6" for Foo

Create an archive tree called "Origin: Foo" as the following.

$ umask 022
$ mkdir -p ~/public_html/debian/pool/main
$ mkdir -p ~/public_html/debian/dists/unstable/main/binary-amd64
$ mkdir -p ~/public_html/debian/dists/unstable/main/source
$ cd ~/public_html/debian
$ cat > dists/unstable/main/binary-amd64/Release << EOF
Archive: unstable
Version: 4.0
Component: main
Origin: Foo
Label: Foo
Architecture: amd64
EOF
$ cat > dists/unstable/main/source/Release << EOF
Archive: unstable
Version: 4.0
Component: main
Origin: Foo
Label: Foo
Architecture: source
EOF
$ cat >aptftp.conf <<EOF
APT::FTPArchive::Release {
  Origin "Foo";
  Label "Foo";
  Suite "unstable";
  Codename "sid";
  Architectures "amd64";
  Components "main";
  Description "Public archive for Foo";
};
EOF
$ cat >aptgenerate.conf <<EOF
Dir::ArchiveDir ".";
Dir::CacheDir ".";
TreeDefault::Directory "pool/";
TreeDefault::SrcDirectory "pool/";
Default::Packages::Extensions ".deb";
Default::Packages::Compress ". gzip bzip2";
Default::Sources::Compress "gzip bzip2";
Default::Contents::Compress "gzip bzip2";

BinDirectory "dists/unstable/main/binary-amd64" {
  Packages "dists/unstable/main/binary-amd64/Packages";
  Contents "dists/unstable/Contents-amd64";
  SrcPackages "dists/unstable/main/source/Sources";
};

Tree "dists/unstable" {
  Sections "main";
  Architectures "amd64 source";
};
EOF

You can automate repetitive updates of APT archive contents on your server system by configuring dupload.

Place all package files into "~foo/public_html/debian/pool/main/" by executing "dupload -t foo changes_file" in client while having "~/.dupload.conf" containing the following.

$cfg{'foo'} = {
  fqdn => "www.example.com",
  method => "scpb",
  incoming => "/home/foo/public_html/debian/pool/main",
  # The dinstall on ftp-master sends emails itself
  dinstall_runs => 1,
};

$cfg{'foo'}{postupload}{'changes'} = "
  echo 'cd public_html/debian ;
  apt-ftparchive generate -c=aptftp.conf aptgenerate.conf;
  apt-ftparchive release -c=aptftp.conf dists/unstable >dists/unstable/Release ;
  rm -f dists/unstable/Release.gpg ;
  gpg -u 3A3CB5A6 -bao dists/unstable/Release.gpg dists/unstable/Release'|
  ssh foo@www.example.com  2>/dev/null ;
  echo 'Package archive created!'";

The postupload hook script initiated by dupload(1) creates updated archive files for each upload.

You can add this small public archive to the apt-line of your client system by the following.

$ sudo bash
# echo "deb http://www.example.com/~foo/debian/ unstable main" \
   >> /etc/apt/sources.list
# apt-key add foo.public.key

You can make a local copy of the package and debconf selection states by the following.

# dpkg --get-selections '*' > selection.dpkg
# debconf-get-selections    > selection.debconf

Here, "*" makes "selection.dpkg" to include package entries for "purge" too.

You can transfer these 2 files to another computer, and install there with the following.

# dselect update
# debconf-set-selections < myselection.debconf
# dpkg --set-selections  < myselection.dpkg
# apt-get -u dselect-upgrade    # or dselect install

If you are thinking about managing many servers in a cluster with practically the same configuration, you should consider to use specialized package such as fai to manage the whole system.

alien(1) enables the conversion of binary packages provided in Red Hat rpm, Stampede slp, Slackware tgz, and Solaris pkg file formats into a Debian deb package. If you want to use a package from another Linux distribution than the one you have installed on your system, you can use alien to convert it from your preferred package format and install it. alien also supports LSB packages.

The current "*.deb" package contents can be extracted without using dpkg(1) on any Unix-like environment using standard ar(1) and tar(1).

# ar x /path/to/dpkg_<version>_<arch>.deb
# ls
total 24
-rw-r--r-- 1 bozo bozo  1320 2007-05-07 00:11 control.tar.gz
-rw-r--r-- 1 bozo bozo 12837 2007-05-07 00:11 data.tar.gz
-rw-r--r-- 1 bozo bozo     4 2007-05-07 00:11 debian-binary
# mkdir control
# mkdir data
# tar xvzf control.tar.gz -C control
# tar xvzf data.tar.gz -C data

You can also browse package content using the mc command.

You can learn more on the package management from following documentations.