The Debian package is not only an archive of files intended for installation. It is part of a larger whole, and it describes its relationship with other Debian packages (dependencies, conflicts, suggestions). It also provides scripts that enable the execution of commands at different stages in the package's lifecycle (installation, removal, upgrades). These data are used by the package management tools but are not part of the packaged software; they are, within the package, what is called its “meta-information” (information about other information).
5.2.1. Opis: plik control
This file uses a structure similar to email headers (as defined by RFC 2822). For example, for apt, the control file looks like the following:
$ apt-cache show apt
Package: apt
Version: 1.4.8
Installed-Size: 3539
Maintainer: APT Development Team <deity@lists.debian.org>
Architecture: amd64
Replaces: apt-utils (<< 1.3~exp2~)
Depends: adduser, gpgv | gpgv2 | gpgv1, debian-archive-keyring, init-system-helpers (>= 1.18~), libapt-pkg5.0 (>= 1.3~rc2), libc6 (>= 2.15), libgcc1 (>= 1:3.0), libstdc++6 (>= 5.2)
Recommends: gnupg | gnupg2 | gnupg1
Suggests: apt-doc, aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), powermgmt-base, python-apt
Breaks: apt-utils (<< 1.3~exp2~)
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,
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.4.8_amd64.deb
Size: 1231676
MD5sum: 4963240f23156b2dda3affc9c0d416a3
SHA256: bc319a3abaf98d76e7e13ac97ab0ee7c238a48e2d4ab85524be8b10cfd23d50d
5.2.1.1. Zależności: pole Depends
The dependencies are defined in the Depends field in the package header. This is a list of conditions to be met for the package to work correctly — this information is used by tools such as apt in order to install the required libraries, in appropriate versions fulfilling the dependencies of the package to be installed. For each dependency, it is possible to restrict the range of versions that meet that condition. In other words, it is possible to express the fact that we need the package libc6 in a version equal to or greater than “2.15” (written “libc6 (>= 2.15)”). Version comparison operators are as follows:
In a list of conditions to be met, the comma serves as a separator. It must be interpreted as a logical “and”. In conditions, the vertical bar (“|”) expresses a logical “or” (it is an inclusive “or”, not an exclusive “either/or”). Carrying greater priority than “and”, it can be used as many times as necessary. Thus, the dependency “(A or B) and C” is written
A | B, C. In contrast, the expression “A or (B and C)” should be written as “(A or B) and (A or C)”, since the
Depends field does not tolerate parentheses that change the order of priorities between the logical operators “or” and “and”. It would thus be written
A | B, A | C.
The dependencies system is a good mechanism for guaranteeing the operation of a program, but it has another use with “meta-packages”. These are empty packages that only describe dependencies. They facilitate the installation of a consistent group of programs preselected by the meta-package maintainer; as such, apt install meta-package will automatically install all of these programs using the meta-package's dependencies. The gnome, kde-full and linux-image-amd64 packages are examples of meta-packages.
5.2.1.2. Konflikty: pole Conflicts
Pole Konflikty wskazuje przypadek, kiedy pakiet nie może być zainstalowany równocześnie z innym. Najczęstszymi powodami takich sytuacji jest plik o tej samej nazwie zawierany przez oba pakiety lub taka sama usługa na tym samym porcie TCP, lub wzajemne utrudnianie sobie działania.
dpkg will refuse to install a package if it triggers a conflict with an already installed package, except if the new package specifies that it will “replace” the installed package, in which case dpkg will choose to replace the old package with the new one. apt always follows your instructions: if you choose to install a new package, it will automatically offer to uninstall the package that poses a problem.
5.2.1.3. Niekompatybilności: pole Breaks
The Breaks field has an effect similar to that of the Conflicts field, but with a special meaning. It signals that the installation of a package will “break” another package (or particular versions of it). In general, this incompatibility between two packages is transitory, and the Breaks relationship specifically refers to the incompatible versions.
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. Dostarczone elementy: pole Provides
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. Wymienność z innymi pakietami
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.24 present in Stretch). 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.
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. Ubiegłe ograniczenia
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 Stretch. 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. Zastępowanie plików: pole Replaces
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.
Użycie tego pola jest uprawnione kiedy zmienia się nazwa pakietu lub jeden pakiet jest zawarty w innym. Zdarza się to również, gdy opiekun decyduje się na różne rozprowadzanie plików pośród różnych pakietów binarnych wytworzonych z tego samego pakietu źródłowego: zastąpiony plik nie należy już do starego pakietu, ale tylko do nowego.
Jeżeli wszystkie pliki w zainstalowanym pakiecie zostały zastąpione, pakiet uważa się za usunięty. Ostatecznie, użycie tego pola zachęca dpkg do usunięcia zastąpionego pakietu, w którym występuje konflikt.
5.2.2. Skrypty konfiguracyjne
W dodatku do pliku control, archiwum control.tar.gz dla każdego pakietu Debiana może zawierać wiele skryptów, wywoływanych przez dpkg na różnych etapach przetwarzania pakietu. Polityka Debiana szczegółowo opisuje możliwe przypadki, wskazując wywoływane skrypty oraz argumenty, które mogą przyjmować. Mogą to być skomplikowane sekwencje, ponieważ jeżeli jeden skrypt zakończy się niepowodzeniem, dpkg będzie próbował powrócić do prawidłowego stanu poprzez anulowanie postępu instalacji lub usuwania (jeżeli tylko będzie to możliwe).
Ogólnie, skrypt preinst jest wykonywany przed instalacją pakietu, podczas gdy postinst następuje po niej. Podobnie, prerm jest wywoływany przez usunięciem pakietu, a postrm po nim. Aktualizacja pakietu jest równoznaczna z usunięciem poprzedniej wersji i instalacją nowej. Nie możliwe jest opisanie tutaj wszystkich możliwych scenariuszy, ale zostaną omówione dwa najczęściej występujące: instalacja/aktualizacja oraz usunięcie.
5.2.2.1. Instalacja i uaktualnieni
Oto, co dzieje się podczas instalacji (lub aktualizacji):
W celu aktualizacji, dpkg wywołuje old-prerm upgrade nowa-wersja.
Nadal w przypadku aktualizacji, dpkg wywołuje new-preinst upgrade stara-wersja; w przypadku pierwszej instalacji wywołuje new-preinst install. Może dodać starą wersję jako ostatni parametr, jeżeli pakiet był wcześniej zainstalowany i usunięty (ale nie całkowicie, gdyż zostały zatrzymane pliki konfiguracyjne).
Nowe pliki pakietu są wtedy rozpakowywane. Jeżeli plik już istnieje, zostaje zastąpiony, ale jest tworzona tymczasowa kopia zapasowa.
W przypadku aktualizacji, dpkg wykonuje old-postrm upgrade nowa-wersja.
dpkg aktualizuje wszystkie wewnętrzne dane (listę plików, skrypty konfiguracyjne, itd.) i usuwa kopie zapasowe zastąpionych plików. Jest to punkt bez powrotu: dpkg nie ma już dostępu do wszystkich elementów niezbędnych do przywrócenia poprzedniego stanu.
Ostatecznie, dpkg konfiguruje pakiet poprzez wykonanie new-postinst configure ostatnia-wersja-configured.
5.2.2.2. Usuwanie pakietu
O to, co zachodzi podczas usuwania pakietu:
dpkg wywołuje prerm remove.
dpkg usuwa wszystkie pliki pakietu, z wyjątkiem plików konfiguracyjnych i skryptów konfiguracyjnych.
dpkg wykonuje postrm remove. Wszystkie skrypty konfiguracyjne, poza postrm, zostają usunięte. Jeżeli użytkownik nie użył opcji "purge", proces dobiega końca.
Podczas całkowitego usuwania pakietów (po wykonaniu polecenia dpkg --purge lub dpkg -P), usuwane są również pliki konfiguracyjne, wraz z pewną liczbą ich kopii (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) i plików tymczasowych; następnie dpkg wykonuje postrm purge.
Opisane powyżej cztery skrypty są uzupełnione skryptem config, dostarczanym przez pakiety używające debconf w celu uzyskania informacji konfiguracyjnych od użytkownika. Podczas instalacji, skrypt ten szczegółowo definiuje pytania zadawane przez debconf. Odpowiedzi są zapisywane w bazie danych debconf dla przyszłego odniesienia. Ten skrypt jest zazwyczaj wykonywany przez apt przed instalacją pakietów jeden po drugim, w celu zgrupowania wszystkich pytań i zadania ich użytkownikowi wszystkich na raz na początku procesu. Skrypty przed- i po-instalacyjne mogą wtedy użyć tych informacji do działania zgodnie z życzeniem użytkownika.
5.2.3. Sumy kontrolne, lista plików konfiguracyjnych
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
Sekcja 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 listuje pliki pakietów, które muszą być obsługiwane jako pliki konfiguracyjne. Pliki konfiguracyjne mogą być modyfikowane przez administratora, a dpkg spróbuje przechować zmiany podczas aktualizacji pakietu.
W istocie, w tej sytuacji dpkg zachowuje się na tyle inteligentnie, na ile to możliwe: jeżeli standardowy plik konfiguracyjny nie został zmieniony pomiędzy dwoma wersjami, nie robi nic. Jeżeli jednak plik był modyfikowany, spróbuje go uaktualnić. Są możliwe dwa przypadki: albo administrator nie modyfikował tego pliku konfiguracyjnego, w tym przypadku dpkg automatycznie instaluje nową wersję; albo plik był modyfikowany, w tym przypadku dpkg pyta administratora, której wersji chciałby użyć (starą ze zmianami albo nową dostarczoną wraz z pakietem). Dla ułatwienia podjęcia tej decyzji dpkg oferuje wyświetlenie “diff”, który pokazuje różnice pomiędzy dwiema wersjami. Jeżeli użytkownik postanowi zachować starą wersję, nowa będzie zachowana w tej samej lokalizacji, w pliku o rozszerzeniu .dpkg-dist. Jeżeli użytkownik wybierze nową wersję, stara będzie zachowana w pliku o rozszerzeniu .dpkg-old. Inna możliwa akcja polega na chwilowym przerwaniu dpkg w celu modyfikacji pliku i próby dokonania odpowiednich zmian (poprzednio zidentyfikowanych za pomocą diff).
