Product SiteDocumentation Site

5.2. Package Meta-Information

Gói Debian không chỉ là một lưu trữ của các tệp tin dành cho cài đặt. Nó là một phần tổng thế lớn hơn, và nó mô tả mối quan hệ với các gói Debian khác (phụ thuộc, xung đột hay gợi ý). Nó còn cung cấp các kịch bản cho phép thực hiện các câu lệnh ở các giai đoạn khác nhau trong vòng đời của gói (cài đặt, gỡ bỏ và nâng cấp). Các dữ liệu này được sử dụng bởi trình quản lý gói nhưng không phải là một phần của phần mềm đóng gói; những dữ liệu trong gói, được gọi với tên là “meta-information” (thông tin về các thông tin khác).

5.2.1. Mô tả: tệp tin control

Tệp này sử dụng một cấu trúc giống như headers của email (định nghĩa ở RFC 2822). Ví dụ, cho gói apt, tệp tin control trông giống như sau:
$ apt-cache show apt
Package: apt
Version: 1.0.9.6
Installed-Size: 3788
Maintainer: APT Development Team <deity@lists.debian.org>
Architecture: amd64
Replaces: manpages-it (<< 2.80-4~), manpages-pl (<< 20060617-3~), openjdk-6-jdk (<< 6b24-1.11-0ubuntu1~), sun-java5-jdk (>> 0), sun-java6-jdk (>> 0)
Depends: libapt-pkg4.12 (>= 1.0.9.6), libc6 (>= 2.15), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.9), debian-archive-keyring, gnupg
Suggests: aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), apt-doc, python-apt
Conflicts: python-apt (<< 0.7.93.2~)
Breaks: manpages-it (<< 2.80-4~), manpages-pl (<< 20060617-3~), openjdk-6-jdk (<< 6b24-1.11-0ubuntu1~), sun-java5-jdk (>> 0), sun-java6-jdk (>> 0)
Description-en: commandline package manager
 This package provides commandline tools for searching and
 managing as well as querying information about packages
 as a low-level access to all features of the libapt-pkg library.
 .
 These include:
  * apt-get for retrieval of packages and information about them
    from authenticated sources and for installation, upgrade and
    removal of packages together with their dependencies
  * apt-cache for querying available information about installed
    as well as installable packages
  * apt-cdrom to use removable media as a source for packages
  * apt-config as an interface to the configuration settings
  * apt-key as an interface to manage authentication keys
Description-md5: 9fb97a88cb7383934ef963352b53b4a7
Tag: admin::package-management, devel::lang:ruby, hardware::storage,
 hardware::storage:cd, implemented-in::c++, implemented-in::perl,
 implemented-in::ruby, interface::commandline, network::client,
 protocol::ftp, protocol::http, protocol::ipv6, role::program,
 role::shared-lib, scope::application, scope::utility, sound::player,
 suite::debian, use::downloading, use::organizing, use::searching,
 works-with::audio, works-with::software:package, works-with::text
Section: admin
Priority: important
Filename: pool/main/a/apt/apt_1.0.9.6_amd64.deb
Size: 1107560
MD5sum: a325ccb14e69fef2c50da54e035a4df4
SHA1: 635d09fcb600ec12810e3136d51e696bcfa636a6
SHA256: 371a559ce741394b59dbc6460470a9399be5245356a9183bbeea0f89ecaabb03

5.2.1.1. Các phụ thuộc: trường Depends

Các phụ thuộc được định nghĩa ở trường Depends trong tiêu đề gói. Đây là danh sách các điều kiện để đáp ứng cho các gói làm việc chính xác - thông tin này được sử dụng bởi các công cụ như apt để cài đặt các thư viện cần thiết, với các phiên bản thích hợp phù hợp với các sự phụ thuộc của gói được cài đặt. Đối với mỗi phụ thuộc, nó có thể hạn chế phạm vi của các phiên bản đáp ứng được điều kiện đó. Nói cách khác, nó có thể để bày tỏ một thực tế rằng chúng ta cần gói libc6 trong một phiên bản tương đương hoặc lớn hơn “2.15” (viết “libc6 (>= 2.15)”). Toán tử so sánh phiên bản như sau:
  • <<: bé hơn;
  • <=: bé hơn hoặc bằng;
  • =: bằng (hãy nhớ “2.6.1” không bằng với “2.6.1-1”);
  • >=: lớn hơn hoặc bằng;
  • >>: lớn hơn.
Trong danh sách các điều kiện cần đáp ứng, các dấu phẩy xem như là một dấu phân cách. Nó phải được hiểu như là toán tử logic “and”. Trong các điều kiện, các thanh dọc (“|”) thể hiện là một toán tử logic “or” (đó là phép hội “or”, không phải là hoặc cái này hoặc cái kia độc quyền “either/or”). Phép “and” được ưu tiên hơn, nó có thể được sử dụng như nhiều lần khi cần thiết. Do đó, sự phụ thuộc “(A or B) and C” được viết A | B, C. Ngược lại, khái niệm “A or (B and C)” nên viết là “(A or B) and (A or C)”, khi trường Depends không có dấu ngoặc mà thay đổi thứ tự ưu tiên giữa các toán tử logic “or” and “and”. Như vậy sẽ được viết thành A | B, A | C.
Hệ thống phụ thuộc là một cơ chế tốt để đảm bảo các hoạt động của một chương trình, nhưng nó còn sử dụng cho “meta-packages”. Đây là gói không chứa nội dung chương trình mà chỉ mô tả phụ thuộc. Nó tạo điều kiện cho quá trình cài đặt của một nhóm các chương trình được phù hợp chọn trước bởi nhà bảo trì meta-package; như vậy, apt install meta-package sẽ tự động cài đặt tất cả các chương trình sử dụng các phụ thuộc của meta-package. Các gói gnome, kde-full and linux-image-amd64 là ví dụ của meta-packages.

5.2.1.2. Xung đột: trường Conflicts

Trường Conflicts chỉ ra rằng khi một gói không thể cài đặt trong trường hơp với gói khác. Phần lớn lý do chung cho vấn đề này là cả hai gói đều bao gốm giống tên nhau, hoặc cung cấp các dịch vụ như nhau ở cùng cồng TCP, hoặc sẽ cản trở hoạt động của gói kia.
dpkg sẽ từ chối cài đặt một gói nếu nó gây xung đột với một trong các gói đã cài đặt, ngoại trừ gói mới đặc biệt nó sẽ “thay thế” gói đã cài đặt, trong trường hợp dpkg sẽ chọn để thay thế gói cũ với gói mới, nó sẽ tự động đề nghị gỡ bỏ gói có vẻ có vấn đề

5.2.1.3. Không tương thích: Trường Breaks

Trường Breaks có tác dụng khá giống với trường Conflicts, nhưng với một nghĩa đặc biệt. Nó báo hiệu rằng nếu cài đặt gói này sẽ “làm hỏng” gói khác (hoặc cụ thể là phiên bản của nó). Nói chung, sự không thương thích này giữa hai gói là tạm thời, và trường Breaks quan hệ đặc biết với các phiên bản không tương thích.
dpkg will refuse to install a package that breaks an already installed package, and apt will try to resolve the problem by updating the package that would be broken to a newer version (which is assumed to be fixed and, thus, compatible again).
This type of situation may occur in the case of updates without backwards compatibility: this is the case if the new version no longer functions with the older version, and causes a malfunction in another program without making special provisions. The Breaks field prevents the user from running into these problems.

5.2.1.4. Provided Items: the Provides Field

This field introduces the very interesting concept of a “virtual package”. It has many roles, but two are of particular importance. The first role consists in using a virtual package to associate a generic service with it (the package “provides” the service). The second indicates that a package completely replaces another, and that for this purpose it can also satisfy the dependencies that the other would satisfy. It is thus possible to create a substitution package without having to use the same package name.
5.2.1.4.1. Providing a “Service”
Let us discuss the first case in greater detail with an example: all mail servers, such as postfix or sendmail are said to “provide” the mail-transport-agent virtual package. Thus, any package that needs this service to be functional (e.g. a mailing list manager, such as smartlist or sympa) simply states in its dependencies that it requires a mail-transport-agent instead of specifying a large yet incomplete list of possible solutions (e.g. postfix | sendmail | exim4 | …). Furthermore, it is useless to install two mail servers on the same machine, which is why each of these packages declares a conflict with the mail-transport-agent virtual package. A conflict between a package and itself is ignored by the system, but this technique will prohibit the installation of two mail servers side by side.
5.2.1.4.2. Interchangeability with Another Package
The Provides field is also interesting when the content of a package is included in a larger package. For example, the libdigest-md5-perl Perl module was an optional module in Perl 5.6, and has been integrated as standard in Perl 5.8 (and later versions, such as 5.20 present in Jessie). As such, the package perl has since version 5.8 declared Provides: libdigest-md5-perl so that the dependencies on this package are met if the user has Perl 5.8 (or newer). The libdigest-md5-perl package itself has eventually been deleted, since it no longer had any purpose when old Perl versions were removed.
Use of a Provides field in order to not break dependencies

Hình 5.1. Use of a Provides field in order to not break dependencies

This feature is very useful, since it is never possible to anticipate the vagaries of development, and it is necessary to be able to adjust to renaming, and other automatic replacement, of obsolete software.
5.2.1.4.3. Past Limitations
Virtual packages used to suffer from some limitations, the most significant of which was the absence of a version number. To return to the previous example, a dependency such as Depends: libdigest-md5-perl (>= 1.6), despite the presence of Perl 5.10, would never be considered as satisfied by the packaging system — while in fact it most likely is satisfied. Unaware of this, the package system chose the least risky option, assuming that the versions do not match.
This limitation has been lifted in dpkg 1.17.11, and is no longer relevant in Jessie. Packages can assign a version to the virtual packages they provide with a dependency such as Provides: libdigest-md5-perl (= 1.8).

5.2.1.5. Replacing Files: The Replaces Field

The Replaces field indicates that the package contains files that are also present in another package, but that the package is legitimately entitled to replace them. Without this specification, dpkg fails, stating that it can not overwrite the files of another package (technically, it is possible to force it to do so with the --force-overwrite option, but that is not considered standard operation). This allows identification of potential problems and requires the maintainer to study the matter prior to choosing whether to add such a field.
The use of this field is justified when package names change or when a package is included in another. This also happens when the maintainer decides to distribute files differently among various binary packages produced from the same source package: a replaced file no longer belongs to the old package, but only to the new one.
If all of the files in an installed package have been replaced, the package is considered to be removed. Finally, this field also encourages dpkg to remove the replaced package where there is a conflict.

5.2.2. Configuration Scripts

In addition to the control file, the control.tar.gz archive for each Debian package may contain a number of scripts, called by dpkg at different stages in the processing of a package. The Debian Policy describes the possible cases in detail, specifying the scripts called and the arguments that they receive. These sequences may be complicated, since if one of the scripts fails, dpkg will try to return to a satisfactory state by canceling the installation or removal in progress (insofar as it is possible).
In general, the preinst script is executed prior to installation of the package, while the postinst follows it. Likewise, prerm is invoked before removal of a package and postrm afterwards. An update of a package is equivalent to removal of the previous version and installation of the new one. It is not possible to describe in detail all the possible scenarios here, but we will discuss the most common two: an installation/update and a removal.

5.2.2.1. Installation and Upgrade

Here is what happens during an installation (or an update):
  1. For an update, dpkg calls the old-prerm upgrade new-version.
  2. Still for an update, dpkg then executes new-preinst upgrade old-version; for a first installation, it executes new-preinst install. It may add the old version in the last parameter, if the package has already been installed and removed since (but not purged, the configuration files having been retained).
  3. The new package files are then unpacked. If a file already exists, it is replaced, but a backup copy is temporarily made.
  4. For an update, dpkg executes old-postrm upgrade new-version.
  5. dpkg updates all of the internal data (file list, configuration scripts, etc.) and removes the backups of the replaced files. This is the point of no return: dpkg no longer has access to all of the elements necessary to return to the previous state.
  6. dpkg will update the configuration files, asking the user to decide if it is unable to automatically manage this task. The details of this procedure are discussed in Phần 5.2.3, “Checksums, List of Configuration Files”.
  7. Finally, dpkg configures the package by executing new-postinst configure last-version-configured.

5.2.2.2. Package Removal

Here is what happens during a package removal:
  1. dpkg calls prerm remove.
  2. dpkg removes all of the package's files, with the exception of the configuration files and configuration scripts.
  3. dpkg executes postrm remove. All of the configuration scripts, except postrm, are removed. If the user has not used the “purge” option, the process stops here.
  4. For a complete purge of the package (command issued with dpkg --purge or dpkg -P), the configuration files are also deleted, as well as a certain number of copies (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) and temporary files; dpkg then executes postrm purge.
The four scripts detailed above are complemented by a config script, provided by packages using debconf to acquire information from the user for configuration. During installation, this script defines in detail the questions asked by debconf. The responses are recorded in the debconf database for future reference. The script is generally executed by apt prior to installing packages one by one in order to group all the questions and ask them all to the user at the beginning of the process. The pre- and post-installation scripts can then use this information to operate according to the user's wishes.

5.2.3. Checksums, List of Configuration Files

In addition to the maintainer scripts and control data already mentioned in the previous sections, the control.tar.gz archive of a Debian package may contain other interesting files. The first, md5sums, contains the MD5 checksums for all of the package's files. Its main advantage is that it allows dpkg --verify (which we will study in Phần 14.3.3.1, “Auditing Packages with dpkg --verify) to check if these files have been modified since their installation. Note that when this file doesn't exist, dpkg will generate it dynamically at installation time (and store it in the dpkg database just like other control files).
conffiles lists package files that must be handled as configuration files. Configuration files can be modified by the administrator, and dpkg will try to preserve those changes during a package update.
In effect, in this situation, dpkg behaves as intelligently as possible: if the standard configuration file has not changed between the two versions, it does nothing. If, however, the file has changed, it will try to update this file. Two cases are possible: either the administrator has not touched this configuration file, in which case dpkg automatically installs the new version; or the file has been modified, in which case dpkg asks the administrator which version they wish to use (the old one with modifications, or the new one provided with the package). To assist in making this decision, dpkg offers to display a “diff” that shows the difference between the two versions. If the user chooses to retain the old version, the new one will be stored in the same location in a file with the .dpkg-dist suffix. If the user chooses the new version, the old one is retained in a file with the .dpkg-old suffix. Another available action consists of momentarily interrupting dpkg to edit the file and attempt to re-instate the relevant modifications (previously identified with diff).