Chapter 2.2 System Debian package management

2.2.1 Overview of Debian packages

Packages generally contain all the files needed to implement a set of related commands or features. There are two types of Debian packages:

Binary packages, which contain executables, configuration files, man / info pages, copyright information and other documentation. These packages are distributed in a specific file format for Debian (see Debian package format, Section 2.2.2), which are distinguished by having a. Deb file extension. Binary packages can be unpacked using the Debian utility dpkg details are provided in the manual page.

Source packages, which consist of a. Dsc file describing the package (including the names of the files that follow), a. Orig.tar.gz that contains the original unmodified source in gzip-compressed tar format and usually , a. diff.gz containing the changes to the original source Debian-specific. The utility dpkg-source packs and unpacks Debian source archives; details are provided in the manual page.

The installation of software by the package system uses "dependencies" which are declared by the persons in charge of the packages. These dependencies are documented in the control associated with each package. For example, the package containing the GNU C compiler gcc Depends on the package binutils which includes the linker and assembler. If a user attempts to install gcc without having first installed binutils the package management system (dpkg) will print an error message saying that it also needs binutils and stop installing gcc (but insistent user can ignore, see dpkg(8) For details, see Package dependencies, Section 2.2.8 below.

The tools of Debian packages can be used to:

manipulate and manage packages or parts of packages,

help the user to divide packets to be distributed through limited-size medium such as floppy disks,

aid developers in building packages and

help users to install packages which are in remote Debian archive site.

2.2.2 Debian package format

A Debian "package" or a Debian archive contains the executable files, libraries and documentation associated with a particular program or set of related programs. Normally, a Debian archive file has a filename ending in. Deb.

The internal structure of the format of Debian binary packages are described in the manual page deb(5) Because the internal format is subject to change (between major releases of Debian), always use dpkg-deb(1) for manipulating. Deb. [1]

The internals of the binary package format are described in the Debian manpage deb(5) Since this format is subject to change (between major releases of Debian), always use dpkg-deb(1) for manipulating. Deb.

At least the Sarge distribution, all Debian archive files are manipulated by the standard Unix commands ar and tar even when the command dpkg are not available.

2.2.3 Naming conventions for Debian package to

The names of Debian packages to the following convention:

  foo _ ver - rev _ arch. deb

usually where foo is the package name, ver is the version, rev is the revision number and arch is the architecture. Of course, the files can be easily renamed. You can find out what package is really contained in a file name filename by running the following command:

  dpkg - info filename

The revision number is assigned by the Debian developer or by whoever built the package. A change in revision number usually indicates that some aspect of the packaging changed.

2.2.4 Preservation of local configuration

The files that can be modified by the local administrator are kept in /etc/ Debian policy dictates that package upgrades must retain all changes to local configuration files.

If the package itself is a default version of a locally configurable file it is called "conffile". The package management system does not update the configuration files that have been modified by the administrator. Moreover, if the configuration file has not been changed by the administrator, then it will be upgraded along with the rest of the package.

For dstar configuration files to a package run the following command:

  dpkg - status package

and see the line "Conffiles".

For more information about the configuration files can read the section "Configuration Files" in the Debian Policy Manual (see References, Section 15.1).

2.2.5 Debian maintenance scripts

The Debian maintenance scripts are executable scripts which are automatically run before or after installation of a package. All of these files, along with other known control are part of the "control" of a Debian archive.

The individual files are:

preinst: This script executes before its package is unpacked from its Debian archive (. Deb). Many "preinst" scripts stop services for packages that are being updated until the update or installation is completed (after the successful execution of the "postinst").

postinst: This script typically completes any required configuration of a package once unpacked from its Debian archive (. Deb). Often, "postinst" scripts ask the user for input, and / or warn that if you accept the defaults back and reconfigure the package as the situation demands. Many "postinst" scripts then execute any commands necessary to restart the service once a new package has been installed or upgraded.

prerm: This script typically stops any daemons associated with a package. It is executed before the removal of files associated with it.

postrm: This script typically modifies links or other files associated with a package and / or removes files created by him (see also Virtual packages, Section 2.2.7.)

Currently, all control files can be found in the directory /var/lib/dpkg/info The files to package foo begin with the word "foo" and have file extensions of "preinst", "postinst", etc.., As appropriate. The file loquesea.list that directory lists all files that were installed with the package foo (Note that the location of these files is a dpkg and may be subject to change)

2.2.6 Package priorities

Those involved in the distribution, assign each a priority Debian package to help the package management system. The priorities are:

Required packages are necessary for the proper functioning of sistema.Esto includes all the tools necessary to repair the system. You must not remove these packages that could disable your system and may even be unable to use dpkg to restore things. Systems with only the Required packages are probably not usable, but have enough functionality to allow the sysadmin to boot and install more software.

Important packages are commonly found in any other packages Unix.Son type system without which the system will not run well or be totally usable. Does not include Emacs or X11 or TeX or any other large applications. These packages only constitute the basic infrastructure.

Standard packages are those that are in every Linux system, including a system so reasonably small but not too limitado.Esto is what will install by default if the user does not select anything else. Not include many large applications, but includes Emacs (which is more a piece of infrastructure than an application) and a reasonable subset of TeX and LaTeX (if it be possible without X).

Optional packages include all the packages you probably want to install even if you are unfamiliar with them and has no requirements específicos.Esto includes X11, a full TeX distribution, and a host of applications.

Extra packages are those that conflict with others of greater importance and have little use for users who are unfamiliar with them, or specialized requirements to "Optional".

In the description Please note the differences among "Priority: required", "Section: base" and "Essential: yes". "Section: base" means that the package is installed before everything else on a new system. Most of the packages in "Section: base" have the "Priority: required" or at least "Priority: important", and many of them are marked with "Essential: yes". "Essential: yes" means that if the package management system such as dpkg when removing from the need of an extra option to force its removal. For example, libc6 mawk and makedev are "Priority: required" and "Section: base" but are not "Essential: yes".

2.2.7 Virtual packages

A virtual package is a generic name that is assigned to any packet from a group of packages that provide similar basic functionality. For example, both tin and trn programs are news readers, and therefore must satisfy any dependencies required by a program that requires a news reader in order to be useful. It is said to provide the "virtual package" called news-reader

Similarly, many packages such as exim exim4 sendmail and postfix provide the functionality of a mail transport agent. Therefore said to Provide the virtual package mail transport agent If you install one of the two, any program that relies on the installation of a mail transport agent will run smoothly due to the existence of this virtual package.

Debian has a mechanism so that if a system is installed in more than one package that provides the virtual package, the administrator can set one as the preferred package. The relevant command is update-alternatives and are described further in Alternative commands, Section 6.5.3.

2.2.8 Package dependencies

The Debian packaging system handles dependency declarations which are used to express that an installation package requires another to operate.

Package A Depends on Package B if B absolutely must be installed in order to use A. In some cases, A depends not only on B, but a specific version of B. In this case, the version dependency is a lower limit, ie, A Depends on any version of B more recent than some specified version.

Package A recommends Package B if the maintainer judges that most users do not want A without also having the functionality provided by B.

Package A suggests Package B if B contains files that are related to and enhance the functionality of A. The same relationship is expressed by declaring that Package B Enhances Package A.

Package A Conflicts with Package B when A will not operate if B is installed in the system. Often the "Conflicts" with "Replaces".

Replaces Package A Package B when files installed by B are removed or overwritten by files in A.

Package A provides Package B when all the files and functionality of B into A.

More detailed information on using each of these terms can be found in the Handbook for the creation of packages and Policy Manual.

Note that dselect have greater control over packages specified by Recommends and Suggests than apt-get which simply pulls all the packages Depends and leaves all the packages specified by Recommends and Suggests. Both in modern form use APT as programs.

2.2.9 Meaning of "Pre-Depends"

dpkg package first ever set upon which another depends. However, dpkg normally unpacks archive files of arbitrarily Indpendient units (Unpacking consists of removing the package files and place them in the right place) However, if a package Pre-Depends on another last will unpack and configure first. [2] The use of this dependency is kept to a minimum.

2.2.10 Package status

The status of a package can be "unknown" (unknown), "install" (to install), "remove" (to kill), "purge" (to purge), or "hold" (on hold). These flags indicate what the user wants to do with a package (as indicated by user actions in the "Select" section of dselect or by directly invoking dpkg by the same).

Meanings:

unknown (unknown) - the user has never indicated whether he wants the package.

install (to install) - the user to install or upgrade the package.

remove (to remove) - the user wants to delete the package but not its existing configuration files.

purge (to purge) - the user wants to completely eliminate the package and its configuration files.

hold (to keep) - the user does not want the package to be processed, ie, wants to keep the current version with the state, whatever that is.

2.2.11 Holding back packages from an upgrade

There are two mechanisms for updating a package by dpkg or, beginning with Woody, through APT.

With dpkg first export the list of package selections:

  dpkg - get-selections> selections.txt

Then edit the resulting file selecciones.txt changing the line that contains the package you wish to hold, eg libc6 from:

  libc6 install

to:

  libc6 hold

Save and update the database dpkg doing:

  dpkg - set-selections selections.txt

Or, if you know the package name to hold, simply run:

  echo libc6 hold | dpkg - set-selections

This procedure holds packages at the installation of each package.

The same effect can be obtained through dselect Simply enter the screen [S] elect, find the package whose state want to keep and press the `= 'key (or` H'). The changes will take effect immediately upon leaving the screen.

Woody distribution in the APT system pose a new alternative mechanism for holding packages during the archive retrieval process. Using Pin-Priority. See the manual page apt_preferences(5) along with http://www.debian.org/doc/manuals/apt-howto/ or package apt-howto

2.2.12 Source packages

Source packages are distributed in a directory called source and can be downloaded manually, or use

  apt-get source foo

to fetch them (see the manual page apt-get(8) for how to set up APT for doing that).

2.2.13 Building binary packages from a source package

For a package foo, you need all loquesea_*.dsc loquesea_*.tar.gz and loquesea_*.diff.gz to compile the source (note: for a Debian native package. Diff.gz).

Once you have them, and if you have installed the package dpkg-dev the command

  dpkg-source-x foo_version-revision. dsc

extract the package into a directory called foo-version.

Run the following command to build the binary package:

  $ Cd foo-version
      $ Su-c "apt-get update, apt-get install fakeroot"
      $ Dpkg-buildpackage-rfakeroot-us-uc

Finally then,

  # Su-c "dpkg-i .. / foo_version-revision_arch. Deb"

to install the newly built package. See Port a package to the stable system, Section 6.4.10.

2.2.14 Creating new Debian packages

For more detailed information, see the New Maintainers' Guide Debian package available in the package maint-guide or http://www.debian.org/doc/manuals/maint-guide/

Popularity: 1%

...::: Guatewireless.org ::::..