차례
이 장은 저수준 내부 데비안 패키지 관리를 다룹니다. 도구 사용법에 주로 관심이 있다면 8장. 데비안 패키지 관리 도구 및 9장. 데비안 시스템 최신으로 유지하기로 건너뛰세요.
패키지에는 일반적으로 일련의 관련 명령 또는 기능을 구현하는 데 필요한 모든 파일이 들어갑니다. 데비안 패키지에 있는 두 가지 유형:
Binary packages, which contain executables,
configuration files, man/info pages, copyright information, and other
documentation. These packages are distributed in a Debian-specific archive
format (see 7.2절. “데비안 바이너리 패키지 형식은 무엇인가요?”); they are usually characterized by
having a '.deb' file extension. Binary packages can be unpacked using the
Debian utility dpkg
(possibly via a frontend like
apt); details are given in its manual page.
Source packages, which consist of a
.dsc
file describing the source package (including the
names of the following files), a .orig.tar.gz
file that
contains the original unmodified source in gzip-compressed tar format and
usually a .debian.tar.xz
file that contains the
Debian-specific changes to the original source. The utility
dpkg-source
packs and unpacks Debian source archives;
details are provided in its manual page. (The program
apt-get can be used as a frontend for
dpkg-source
.)
Installation of software by the package system uses "dependencies" which are
carefully designed by the package maintainers. These dependencies are
documented in the control
file 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 send an error message that it also needs binutils
, and stop installing gcc
. (However, this facility can be overridden
by the insistent user, see
dpkg(8).)
See more in 7.9절. “What is meant by saying that a package Depends,
Recommends, Suggests,
Conflicts, Replaces,
Breaks or Provides another
package?” below.
데비안 패키지 도구 사용:
패키지 또는 패키지 일부를 다루고 관리하며,
패키지 안의 파일 지역 무시 관리,
패키지 아카이브 구축에서 개발자 돕기, 그리고
원격 아카이브 사이트에 있는 패키지를 설치하는 사용자 돕기.
A Debian "package", or a Debian archive file, 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 that ends
in .deb
.
데비안 바이너리 패키지 형식 내부는
deb(5)
설명서 페이지에 설명합니다. 내부 형식은 변경될 수 있으며 (Debian GNU/Linux 메이저 릴리스 사이), 그러므로
.deb
파일을 저수준으로 다루려면 언제나
dpkg-deb(1)
을 쓰세요.
The Debian binary package file names conform to the following convention: <DebianPackageName>_<VersionNumber>-<DebianRevisionNumber>_<DebianArchitecture>.deb
Checking the package name associated with a particular Debian archive file (.deb file) can be done in one of these ways:
inspect the "Packages" file in the directory where it was stored at a Debian archive site. This file contains a stanza describing each package; the first field in each stanza is the formal package name.
use the command dpkg --info PPP_VVV-RRR_AAA.deb
(where
PPP, VVV, RRR and AAA are the package name, version, revision and
architecture of the package in question, respectively). This displays,
among other things, the package name corresponding to the archive file being
unpacked.
The VVV
component is the version number specified by the
upstream developer. There are no standards in place here, so the version
number may have formats as different as "19990513" and "1.3.8pre1".
The RRR
component is the Debian revision number, and is
specified by the Debian developer (or a user who chooses to rebuild the
package locally). This number corresponds to the revision level of the
Debian package, thus, a new revision level usually signifies changes in the
Debian Makefile (debian/rules
), the Debian control file
(debian/control
), the installation or removal scripts
(debian/p*
), or in the configuration files used with the
package.
The AAA
component identifies the processor for which the
package was built. This is commonly amd64
, which refers
to AMD64, Intel 64 or VIA Nano chips. For other possibilities review
Debian's archive directory structure at 6.7절. “데비안 아카이브에 있는 그 모든 디렉터리는 무엇인가요?”. For
details, see the description of "Debian architecture" in the manual page
dpkg-architecture(1).
Specifics regarding the contents of a Debian control file are provided in the Debian Policy Manual, section 5, see 12.1절. “데비안 시스템에 다른 어떤 문서가 있나요?”.
Briefly, a sample control file is shown below for the Debian package hello:
Package: hello Version: 2.9-2+deb8u1 Architecture: amd64 Maintainer: Santiago Vila <sanvila@debian.org> Installed-Size: 145 Depends: libc6 (>= 2.14) Conflicts: hello-traditional Breaks: hello-debhelper (<< 2.9) Replaces: hello-debhelper (<< 2.9), hello-traditional Section: devel Priority: optional Homepage: https://www.gnu.org/software/hello/ Description: example package based on GNU hello The GNU hello program produces a familiar, friendly greeting. It allows non-programmers to use a classic computer science tool which would otherwise be unavailable to them. . Seriously, though: this is an example of how to do a Debian package. It is the Debian version of the GNU Project's "hello world" program (which is itself an example for the GNU Project).
The Package field gives the package name. This is the name by which the package can be manipulated by the package tools, and usually similar to but not necessarily the same as the first component string in the Debian archive file name.
The Version field gives both the upstream developer's version number and (in the last component) the revision level of the Debian package of this program as explained in 7.3절. “데비안 패키지 파일 이름은 왜 그리 긴가요?”.
The Architecture field specifies the chip for which this particular binary was compiled.
The Depends field gives a list of packages that have to be installed in order to install this package successfully.
The Installed-Size indicates how much disk space the installed package will consume. This is intended to be used by installation front-ends in order to show whether there is enough disk space available to install the program.
The Section line gives the "section" where this Debian package is stored at the Debian archive sites.
The Priority indicates how important is this package for installation, so that semi-intelligent software like apt or aptitude can sort the package into a category of e.g. packages optionally installed. See 7.7절. “What is an Essential, Required, Important, Standard, Optional, or Extra package?”.
The Maintainer field gives the e-mail address of the person who is currently responsible for maintaining this package.
The Description field gives a brief summary of the package's features.
For more information about all possible fields a package can have, please see the Debian Policy Manual, section 5, "Control files and their fields", see 12.1절. “데비안 시스템에 다른 어떤 문서가 있나요?”.
Conffiles is a list of configuration files (usually placed in
/etc
) that the package management system will not
overwrite when the package is upgraded. This ensures that local values for
the contents of these files will be preserved, and is a critical feature
enabling the in-place upgrade of packages on a running system.
To determine exactly which files are preserved during an upgrade, run:
dpkg --status package
And look under "Conffiles:".
These files are executable scripts which are automatically run before or
after a package is installed or removed. Along with a file named
control
, all of these files are part of the "control"
section of a Debian archive file.
The individual files are:
This script is executed before the package it belongs to is unpacked from its Debian archive (".deb") file. Many 'preinst' scripts stop services for packages which are being upgraded until their installation or upgrade is completed (following the successful execution of the 'postinst' script).
This script typically completes any required configuration of the package
foo
once foo
has been unpacked from
its Debian archive (".deb") file. Many 'postinst' scripts execute any
commands necessary to start or restart a service once a new package has been
installed or upgraded.
This script typically stops any daemons which are associated with a package. It is executed before the removal of files associated with the package.
This script typically modifies links or other files associated with
foo
, and/or removes files created by the package. (Also
see 7.8절. “가상 패키지는 무엇인가요?”.)
Currently all of the control files can be found in the directory
/var/lib/dpkg/info
. The files relevant to package
foo
begin with the name "foo" and have file extensions of
"preinst", "postinst", etc., as appropriate. The file
foo.list
in that directory lists all of the files that
were installed with the package foo
. (Note that the
location of these files is a dpkg internal; you should not rely on it.)
Each Debian package is assigned a priority by the distribution maintainers, as an aid to the package management system. The priorities are:
Required: packages that are necessary for the proper functioning of the system.
This includes all tools that are necessary to repair system defects. You must not remove these packages or your system may become totally broken and you may probably not even be able to use dpkg to put things back. Systems with only the Required packages are probably unusable, but they do have enough functionality to allow the sysadmin to boot and install more software.
Important packages should be found on any Unix-like system.
Other packages which the system will not run well or be usable without will be here. This does NOT include Emacs or X or TeX or any other large application. These packages only constitute the bare infrastructure.
Standard packages are standard on any Linux system, including a reasonably small but not too limited character-mode system. Tools are included to be able to send e-mail (with mutt) and download files from archive servers.
This is what will be installed by default if users do not select anything else. It does not include many large applications, but it does include the Python interpreter and some server software like OpenSSH (for remote administration) and Exim (for mail delivery, although it can be configured for local delivery only). It also includes some common generic documentation that most users will find helpful.
Optional packages include all those that you might reasonably want to install if you do not know what they are, or that do not have specialized requirements.
This includes X, a full TeX distribution, and lots of applications.
Extra: packages that either conflict with others with higher priorities, are only likely to be useful if you already know what they are, or have specialized requirements that make them unsuitable for "Optional".
If you do a default Debian installation all the packages of priority Standard or higher will be installed in your system. If you select pre-defined tasks you will get lower priority packages too.
Additionally, some packages are marked as Essential since they are absolutely necessary for the proper functioning of the system. The package management tools will refuse to remove these.
A virtual package is a generic name that applies to any one of a group of
packages, all of which provide similar basic functionality. For example,
both the konqueror
and firefox-esr
programs are web browsers, and should therefore satisfy any dependency of a
program that requires a web browser on a system, in order to work or to be
useful. They are therefore both said to provide the "virtual package"
called www-browser
.
Similarly, exim4
and sendmail
both
provide the functionality of a mail transport agent. They are therefore
said to provide the virtual package "mail-transport-agent". If either one
is installed, then any program depending on the installation of a
mail-transport-agent
will be satisfied by the presence of
this virtual package.
Debian provides a mechanism so that, if more than one package which provide
the same virtual package is installed on a system, then system
administrators can set one as the preferred package. The relevant command
is update-alternatives
, and is described further in 11.11절. “어떤 사용자는 mawk를 좋아하고, 다른 사람은 gawk를 좋아합니다. 어떤 사람은 vim을 다른 사람은 elvis를 좋아합니다. 어떤
사람은 trn을 다른 사람은 tin을 좋아합니다. 데비안은 다양성을 어떻게 지원하나요?”.
The Debian package system has a range of package "dependencies" which are designed to indicate (in a single flag) the level at which Program A can operate independently of the existence of Program B on a given system:
Package A depends on Package B if B absolutely must be installed in order to run A. In some cases, A depends not only on B, but on a version of B. In this case, the version dependency is usually a lower limit, in the sense that A depends on any version of B more recent than some specified version.
Package A recommends Package B, if the package maintainer judges that most users would 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 usually enhance) the functionality of A.
Package A conflicts with Package B when A will not operate if B is installed on the system. Most often, conflicts are cases where A contains files which are an improvement over those in B. "Conflicts" are often combined with "replaces".
Package A replaces Package B when files installed by B are removed and (in some cases) over-written by files in A.
Package A breaks Package B when both packages cannot be simultaneously configured in a system. The package management system will refuse to install one if the other one is already installed and configured in the system.
Package A provides Package B when all of the files and functionality of B are incorporated into A. This mechanism provides a way for users with constrained disk space to get only that part of package A which they really need.
More detailed information on the use of each of these terms can be found in the Debian Policy manual, section 7.2, "Binary Dependencies", see 12.1절. “데비안 시스템에 다른 어떤 문서가 있나요?”.
"Pre-Depends" is a special dependency. In the case of most packages,
dpkg
will unpack the archive file of a package (i.e., its
.deb
file) independently of whether or not the files on
which it depends exist on the system. Simplistically, unpacking means that
dpkg
will extract the files from the archive file that
were meant to be installed on your file system, and put them in place. If
those packages depend on the existence of some other
packages on your system, dpkg
will refuse to complete the
installation (by executing its "configure" action) until the other packages
are installed.
However, for some packages, dpkg
will refuse even to
unpack them until certain dependencies are resolved. Such packages are said
to "Pre-depend" on the presence of some other packages. The Debian project
provided this mechanism to support the safe upgrading of systems from
a.out
format to ELF
format, where the
order in which packages were unpacked was critical.
There are other large upgrade situations where this method is useful,
e.g. the packages with the required priority and their LibC dependency.
전처럼, 이에 대한 자세한 내용은 정책 매뉴얼에 있습니다.
These "want" flags tell what the user wanted to do with a package (as
indicated by the user's direct invocations of
dpkg
/apt
/
aptitude
).
그것이 뜻하는 것:
unknown - 사용자가 패키지를 원하는지 여부를 지정하지 않았습니다.
install - 패키지가 설치되거나. 업그레이드 되기를 사용자가 바람.
remove - 사용자가 바라는 것은 패키지 제거, 그러나 설정파일을 제거하는 것을 바라지는 않음.
purge - 사용자가 바라는 것은 패키지를 완전히 제거하는 것, 설정 파일도 포함.
hold - 사용자는 이 패키지가 처리되지 않기를 바랍니다. 즉, 현재 상태를 유지하려는 경우입니다.
패키지를 보류하는 3가지 방법. dpkg, apt 또는 aptitude.
With dpkg, you have to export the list of package selections, with:
dpkg --get-selections \* > selections.txt
Then edit the resulting file selections.txt
, change the
line containing the package you wish to hold, e.g. libc6
, from this:
libc6 install
이를 위해:
libc6 hold
Save the file, and reload it into dpkg database with:
dpkg --set-selections < selections.txt
With apt, you can set a package to hold using
apt-mark hold package_name
and remove the hold with
apt-mark unhold package_name
With aptitude, you can hold a package using
aptitude hold package_name
and remove the hold with
aptitude unhold package_name
데비안 소스 패키지는 실제로 "설치"될 수 없으며, 바이너리 패키지를 만들고자 하는 디렉터리에 패키지가 풀릴 뿐입니다.
Source packages are distributed on most of the same mirrors where you can obtain the binary packages. If you set up your APT's sources.list(5) to include the appropriate "deb-src" lines, you'll be able to easily download any source package by running
apt-get source foo
To help you in actually building the source package, Debian source packages provide the so-called build-dependencies mechanism. This means that the source package maintainer keeps a list of other packages that are required to build their package. To see how this is useful, run
apt-get build-dep foo
소스를 빌드 하기 전에.
선호하는 방법은 다양한 래퍼 도구를 사용하는 것입니다. 우리는 그것이 어떻게 이루어졌는지
devscripts
도구를 써서 보여 줄 겁니다. 아직 설치하지 않았다면 이 패키지를 설치하십시오.
이제, 먼저 소스 패키지를 얻습니다:
apt-get source foo
그리고 소스 트리로 바꿉니다:
cd foo-*
Then install needed build-dependencies (if any):
sudo apt-get build-dep foo
Then create a dedicated version of your own build (so that you won't get confused later when Debian itself releases a new version):
dch -l local 'Blah blah blah'
And finally build your package:
debuild -us -uc
If everything worked out fine, you should now be able to install your package by running
sudo dpkg -i ../*.deb
If you prefer to do things manually, and don't want to use
devscripts
, follow this procedure:
You will need all of foo_*.dsc, foo_*.tar.gz and foo_*.debian.tar.xz to compile the source (note: there is no .debian.tar.xz for some packages that are native to Debian).
Once you have them (7.13절. “어떻게 소스 패키지를 설치하나요?”) and if you have the
dpkg-dev
package installed, the
following command:
dpkg-source -x foo_version-revision.dsc
will extract the package into a directory called
foo-version
.
If you just want to compile the package, you may cd into the
foo-version
directory and issue the command
dpkg-buildpackage -rfakeroot -b
패키지를 빌드하려면 (이것은 fakeroot
패키지 필요함을
주의), 그리고
dpkg -i ../foo_version-revision_arch.deb
새로 빌드한 패키지를 설치.
이에 대한 자세한 설명을 보려면 New Maintainers' Guide maint-guide
패키지 또는 https://www.debian.org/doc/devel-manuals#maint-guide, 또는 Guide for
Debian Maintainers, debmake-doc
패키지
https://www.debian.org/doc/devel-manuals#debmake-doc 를 읽으세요.