Linux+: Applications 11 – dpkg Overview

J

Jarret W. Buse

Guest
Linux+: Applications 11 – dpkg Overview

All Linux systems have some type of package manager. The package managers are used to install, upgrade, query, search and remove applications. The package managers that most people are familiar with are either RPM or dpkg. RPM is for Red Hat systems and dpkg is for Debian based systems.

NOTE: Do not confuse dpkg with Aptitude (apt). Aptitude is a command-line front-end for dpkg. Synaptic and other such programs are a GUI front-end for both.

This article covers the use of dpkg from a command-line. It is assumed that packages (files with an extension of deb) are located locally on the system. The Aptitude utility and Synaptic GUI is used to actually perform downloading of the package to the local system. Once the package is downloaded locally, Aptitude or Synaptic calls dpkg in the background to perform the actual desired command on the package.

There are five basic modes for dpkg:

  1. Install : It is used to install any “deb” package.
  2. Remove : It is used to erase, remove or un-install any “deb” package.
  3. Upgrade : It is used to update the existing “deb” package.
  4. Verify : It is used for the verification of any “deb” package.
  5. Query : It is used to query about different “deb” packages.

The syntax for dpkg is:

dpkg option action

NOTE: There must be one action and zero or more options.

Packages, which are archived files containing everything needed to install the application, are Debian based and have an extension of “deb”. Information about the package are maintained by dpkg to three type of classes:

  1. States
  2. Selection States
  3. Flags

NOTE: These classes can be manually changed with the “dselect” action.

Before we discuss the States, let's look at the install process to understand the States better. Once the package has been downloaded, the following occur:

  1. The control files of the package are extracted
  2. Versions are checked and if another version of the same package is installed its “prerm” script is executed. The “prerm” script stops any daemons which cannot be running when the old package files are removed
  3. Run the “preinst” script from the new package. The “preinst” script is used to stop any necessary daemons which cannot be running when the package is installed
  4. Unpack files from new package and also backup old package files in case the install fails
  5. If an older version has been installed, the “postrm” script of old package is run. Removes files created by old package
  6. Configures the new package
The configuration process is done in two steps:

  1. Configuration files are extracted as the old configuration files are backed up
  2. Run “postinst” script which completes any configuration of the package even if the user is prompted for information

The package States shows the current “state” of the package:

  • config-files – all package files are not installed and the only files currently installed are the configuration files
  • half-configured – package has been unpacked and partially configured, but has not been completed
  • half-installed – package installation was started, but not finished
  • installed – package is unpacked and completely configured
  • not-installed – package is not installed on the system
  • triggers-awaited – package needs triggers to be processed by another package
  • triggers-pending – package has been triggered
  • unpacked – package is unpacked, but not yet configured
The package Selection States are used to denote the current state of what has been selected to be done to the package:
  • deinstall – the package has been selected to be removed except for the configuration files
  • install – package has been selected to be installed
  • purge – package is to be removed as well as the configuration files

There is one Flag class:

  • reinst-required – package is broken and a reinstall is required to repair the package

For dpkg, there are Environment Variables which can or will be set to control some of the settings for when the package manager is run.
Files also exist which contain configuration information for dpkg as well as package status for those available to the system.
There also exist other applications for handling dpkg commands:

  • dpkg-deb - used to pack, unpack and list information about a package to the user
  • dpkg-split – used to split/join packages as needed
  • dpkg-query – accesses the dpkg database to gain information
  • dpkg-statoverride – overrides the ownership and mode of file when a package is installed
  • dpkg-divert – overrides the version of a package
  • dpkg-trigger – used to activate triggers for testing

NOTE:
triggers are events which occur, such as a file being deleted or a
package being installed. Triggers can also include how a specific
file is handled when it is clicked. For example, when a text file is
opened, it is loaded into a text editor.

Similar to RPM, dpkg can be a very intricate application, therefore, time
should be spent in learning it.
 

Attachments




Members online


Latest posts


Top