5.2. Meta-informacje pakietu

The Debian package is not only an archive of files intended for installation. It is part of a larger whole and describes its relationship with other Debian packages (requisites, dependencies, conflicts, suggestions). It also provides scripts that enable the execution of commands at different stages in the package's lifecycle (installation, upgrade, removal). 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) and is fully described in the Debian Policy and the manual pages deb-control(5) and deb822(5).

→ https://www.debian.org/doc/debian-policy/ch-controlfields.html

For example, for apt, the control file looks like the following:

$ apt-cache show apt
Package: apt
Version: 2.2.4
Installed-Size: 4337
Maintainer: APT Development Team <[email protected]>
Architecture: amd64
Replaces: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~)
Provides: apt-transport-https (= 2.2.4)
Depends: adduser, gpgv | gpgv2 | gpgv1, libapt-pkg6.0 (>= 2.2.4), debian-archive-keyring, libc6 (>= 2.15), libgcc-s1 (>= 3.0), libgnutls30 (>= 3.7.0), libseccomp2 (>= 2.4.2), libstdc++6 (>= 9), libsystemd0
Recommends: ca-certificates
Suggests: apt-doc, aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), gnupg | gnupg2 | gnupg1, powermgmt-base
Breaks: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~), aptitude (<< 0.8.10)
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, suite::debian, use::downloading,
 use::organizing, use::playing, use::searching, works-with-format::html,
 works-with::audio, works-with::software:package, works-with::text
Section: admin
Priority: required
Filename: pool/main/a/apt/apt_2.2.4_amd64.deb
Size: 1491328
MD5sum: 24d53e8dd75095640a167f40476c0442
SHA256: 75f07c4965ff0813f26623a1164e162538f5e94defba6961347527ed71bc4f3d

Let us have a closer look at the purpose of some of the fields listed by the previous command.

WRACAJĄC DO PODSTAW RFC — internetowe standardy

RFC is the abbreviation of “Request For Comments”. An RFC is generally a technical document that describes what will become an Internet standard. Before becoming standardized and frozen, these standards are submitted for public review (hence their name). The IETF (Internet Engineering Task Force) decides on the evolution of the status of these documents (proposed standard, draft standard, or standard).

RFC 2026 definiuje proces standaryzacji protokołów internetowych

→ http://www.faqs.org/rfcs/rfc2026.html

5.2.1.1. Zależności: pole `Depends`

The dependencies are defined in the Depends field in the package header. It 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, tools, drivers, etc., 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:

<<: mniejsza;
<=: mniejsza bądź równa;
=: równa (zauważ, że “2.6.1” nie jest równa “2.6.1-1”);
>=: większa bądź równa;
>>: większa.

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.

→ https://www.debian.org/doc/debian-policy/ch-relationships.html#syntax-of-relationship-fields

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 pre-selected 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.

POLITYKA DEBIANA Pola Recommends, Suggests i Enhances

The Recommends and Suggests fields describe dependencies that are not compulsory. The “recommended” dependencies, the most important, considerably improve the functionality offered by the package but are not indispensable to its operation. The “suggested” dependencies, of secondary importance, indicate that certain packages may complement and increase their respective utility, but it is perfectly reasonable to install one without the others.

You should always install the “recommended” packages, unless you know exactly why you do not need them. This is now also the default for APT unless configured otherwise. Conversely, it is not necessary to install “suggested” packages unless you know why you need them (the package description or its documentation may contain information which extra functionality they will activate). The behavior of apt can be controlled by using the APT::Install-Recommends and APT::Install-Suggests configuration options or the corresponding command line options --[no-]install-recommends and --[no-]install-suggests.

The Enhances field also describes a suggestion, but in a different context. It is indeed located in the suggested package, and not in the package that benefits from the suggestion. Its interest lies in that it is possible to add a suggestion without having to modify the package that is concerned. Thus, all add-ons, plug-ins, and other extensions of a program can then appear in the list of suggestions related to the software. Although it has existed for several years, this last field is still largely ignored by programs such as apt or synaptic. Its purpose is for a suggestion made by the Enhances field to appear to the user in addition to the traditional suggestions — found in the Suggests field.

DEBIAN POLICY Pre-Depends,bardziej wymagający Depends

“Pre-dependencies”, which are listed in the “Pre-Depends” field in the package headers, complete the normal dependencies; their syntax is identical. A normal dependency indicates that the package in question must be unpacked and configured before configuration of the package declaring the dependency. A pre-dependency stipulates that the package in question must be unpacked and configured before execution of the pre-installation script of the package declaring the pre-dependency, that is before its installation.

A pre-dependency is very demanding for apt, because it adds a strict constraint on the ordering of the packages to install. As such, pre-dependencies are discouraged unless absolutely necessary. It is even recommended to consult other developers on [email protected] before adding a pre-dependency. It is generally possible to find another solution as a workaround.

5.2.1.2. Konflikty: pole `Conflicts`

The Conflicts field indicates when a package cannot be installed simultaneously with another. The most common reasons for this are that both packages include a file of the same name and path, or provide the same service on the same TCP port, or would hinder each other's operation.

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.

POLITYKA DEBIANA Lista pakietów wirtualnych

Aby wirtualne pakiety były przydatne, wszyscy muszą zgadzać się odnośnie ich nazw. Z tego powodu są one ustandaryzowane w Polityce Debiana. Lista obejmuje między innymi mail-transport-agent dla serwerów poczty, c-compiler dla kompilatorów języka C, www-browser dla przeglądarek internetowych, httpd dla serwerów internetowych, ftp-server dla serwerów FTP, x-terminal-emulator dla emulatorów terminala w trybie graficznym (xterm) i x-window-manager dla menedżerów okien.

The full list can be found on the Web.

→ https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml

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.32.1 present in Bullseye). 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.

Rysunek 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.

WRACAJĄC DO PODSTAW Perl, język programowania

Perl (Practical Extraction and Report Language) is a very popular programming language. It has many ready-to-use modules that cover a vast spectrum of applications, and that are distributed by the CPAN (Comprehensive Perl Archive Network) servers, an exhaustive network of Perl packages.

→ https://www.perl.org/

→ https://www.cpan.org/

W związku z tym, że jest to język interpretowany, program napisany w Perlu nie wymaga kompilacji przed wykonaniem. Dlatego nazywa się je "skryptami Perla".

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 have never been considered as satisfied by the packaging system — while in fact it most likely was 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. Packages, like perl 5.32.1, can assign a version to the virtual packages they provide, such as Provides: libdigest-md5-perl (= 2.55.01), and thus allow other packages to use versioned dependencies.

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 to install the package, stating that it cannot 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.

IDĄC DALEJ Pole Tag

In the apt example at the beginning, we can see the presence of a field that we have not yet described, the Tag field. This field does not describe a relationship between packages, but is simply a way of categorizing a package in a thematic taxonomy. This classification of packages according to several criteria (type of interface, programming language, domain of application, etc.) has been available for a long time. Despite this, not all packages have accurate tags and it is not yet integrated in all Debian tools; aptitude displays these tags, and allows them to be used as search criteria. For those who dislike aptitude's search criteria, the following website allows navigation of the tag database:

→ https://wiki.debian.org/Debtags

5.2.2. Skrypty konfiguracyjne

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).

→ https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html

IDĄC DALEJ Baza danych dpkg

Wszystkie skrypty konfiguracyjne dla zainstalowanych pakietów są przechowywane w katalogu /var/lib/dpkg/info/, w formie pliku z przedrostkiem wskazującym nazwę pakietu. Katalog ten dla każdego pakietu zawiera również plik z rozszerzeniem .list, zawierający listę plików należących do danego pakietu.

Plik /var/lib/dpkg/status zawiera szereg bloków danych (w formacie sławnych nagłówków pocztowych, RFC 2822) opisujących status każdego pakietu. Jest tam również powielona informacja z pliku control zainstalowanych pakietów.

In general, the preinst script is executed prior to installation of the package, while 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. Instalacja i uaktualnieni

During the initial installation and for each upgrade of a package, dpkg calls the so called maintainer scripts such as the prerm or preinst scripts. These scripts can perform additional actions during the different stages of a package's life-cycle. Script names preceded by new- are the scripts from the new version of a package being installed or upgraded to. Script names preceded by old- are the scripts from the old version of a package that is being upgraded from.

During each invocation dpkg will pass certain arguments to each script such as upgrade new-version. The invoked script can then either handle the arguments and perform a particular action, or ignore the arguments and return with an exit code of 0, if nothing needs to be done during that step. In practice many packages will not need to perform an action during every step in the life cycle. Thus a typical configuration script will check for a particular argument and ignore all other ones, implicitly returning with exit code 0.

Here is what happens during an installation (or an update). The old-version, new-version and last-version-configured arguments are placeholders for the actual (old and new) version numbers of the package:

For an update, dpkg calls the old-prerm script and passes upgrade new-version as arguments.
Still for an update, dpkg then executes the new-preinst script with the arguments upgrade old-version; for the initial installation, it executes the new-preinst script and passes install as argument. It may add the old version in the last parameter, if the package has already been installed and removed since (but not purged, and thus configuration files have been retained).
Nowe pliki pakietu są wtedy rozpakowywane. Jeżeli plik już istnieje, zostaje zastąpiony, ale jest tworzona tymczasowa kopia zapasowa.
For an update, dpkg executes the old-postrm script and passes upgrade new-version as arguments.
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.
dpkg zaktualizuje pliki konfiguracyjne, pytając użytkownika o decyzje, jeżeli nie jest w stanie automatycznie wykonać tego zadania. Szczegóły tej procedury zostały omówione w Sekcja 5.2.3, „Checksums, List of Configuration Files, et al.”.
Finally, dpkg configures the package by executing the new-postinst script with the arguments configure last-version-configured.

5.2.2.2. Usuwanie pakietu

The steps to remove a package are analogous to the installation steps. The main difference is that the removal scripts of the package are called:

dpkg calls the prerm script and passes the remove argument.
dpkg removes all of the package's files, with the exception of the configuration files and maintainer scripts.
dpkg executes the postrm script and passes remove as argument. Afterwards, all of the maintainer scripts, except the postrm script, are removed. If the user has not used the “purge” option, the process stops here.
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 the postrm script and passes purge as argument.

SŁOWNIK Purge, całkowite usunięcie

Kiedy pakiet Debiana jest usuwany, pliki konfiguracyjne są zatrzymywane w celu ułatwienia ich prawdopodobnej reinstalacji. Podobnie, dane generowane przez demona (takie jak zawartość katalogu serwera LDAP, albo zawartość bazy danych serwera SQL) są zwykle zatrzymywane.

Do usunięcia wszystkich danych powiązanych z pakietem niezbędne jest "całkowite usunięcie" (purge) pakietu komendą, dpkg -P pakiet, apt-get remove --purge pakiet lub aptitude purge pakiet.

Given the definitive nature of such data removals, a purge should not be taken lightly.

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.

NARZĘDZIE debconf

debconf został stworzony, żeby rozwiązać powtarzające się problemy Debiana. Wszystkie pakiety Debiana nie są zdolne do funkcjonowania bez chociażby minimalnej konfiguracji, która zazwyczaj zadaje pytania przy użyciu komend echo oraz read w skryptach postinst (i innych podobnych skryptach). Ale oznacza to także, że podczas większej instalacji lub aktualizacji użytkownik musi zostać przed komputerem odpowiadając na przeróżne pytania, mogące pojawić się w każdej chwili. Tych ręcznych interakcji można teraz niemal całkowicie uniknąć dzięki użyciu narzędzia debconf.

debconf ma wiele interesujących cech: wymaga od dewelopera sprecyzowania interakcji z użytkownikiem; pozwala tłumaczyć wszystkie ciągi znaków wyświetlane użytkownikowi (wszystkie tłumaczenia są przechowywane w pliku templates opisującym interakcje); posiada różne interfejsy do wyświetlania pytań skierowanych do użytkownika (tryb tekstowy, graficzny, bez interaktywny); oraz umożliwia stworzenie centralnej bazy danych odpowiedzi w celu dzielenia tej samej konfiguracji na różnych komputerach... ale najważniejsze jest to, że teraz możliwe jest przedstawienia użytkownikowi wszystkich pytań na raz, przed rozpoczęciem długiej instalacji lub aktualizacji. Użytkownik może zająć się swoimi sprawami, podczas gdy system sam radzi sobie z instalacją, bez konieczności wpatrywania się w ekran w oczekiwaniu na pytanie.

5.2.3. Checksums, List of Configuration Files, et al.

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.4.1, „Auditing Packages with dpkg --verify”) and debsums (from the package of the same name; see Sekcja 14.3.4.2, „Auditing Packages: debsums and its Limits”) to check if these files have been modified since their installation. Note that when this file doesn't exist, which might be the case for some older packages, dpkg will generate it dynamically at installation time (and store it in the dpkg database just like other control files).

The file conffiles lists package files that must be handled as configuration files (see also deb-conffiles(5)). Configuration files can be modified by the administrator, and dpkg will try to preserve those changes during a package update.

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).

IDĄC DALEJ Wymuszanie pytań o pliki konfiguracyjne w dpkg

The --force-confask option requires dpkg to display the questions about the configuration files, even in cases where they would not normally be necessary. Thus, when reinstalling a package with this option, dpkg will ask the questions again for all of the configuration files modified or deleted by the administrator. This is very convenient, especially for reinstalling the original configuration file if it has been deleted and no other copy is available: a normal re-installation won't work, because dpkg considers removal as a form of legitimate modification, and, thus, doesn't install the desired configuration file.

See the sidebar IDĄC DALEJ Unikanie pytań o pliki konfiguracyjne for how to use these options with APT.

IDĄC DALEJ Unikanie pytań o pliki konfiguracyjne

dpkg obsługuje aktualizacje pliku konfiguracyjnego, ale w trakcie działania regularnie przerywa pracę, żeby zapytać administratora o dane wejściowe. To czyni go mniej przyjemnym dla tych, którzy chcieliby uruchomić aktualizacje w sposób bez interaktywny. Właśnie dlatego program ten oferuje opcje pozwalające systemowi na automatyczne odpowiadanie zgodnie z tą samą logiką : --force-confold zatrzymuje starą wersję pliku; --force-confnew użyje nowej wersji pliku (wybory te są przestrzegane, nawet jeżeli plik nie został zmieniony przez administratora, które rzadko dają pożądany efekt). Dodanie opcji --force-confdef mówi dpkg żeby sam decydował, kiedy jest to możliwe (inaczej mówiąc, kiedy oryginalny plik konfiguracyjny nie był modyfikowany) i użył tylko --force-confnew lub --force-confold w innych przypadkach.

These options apply to dpkg and are explained in detail in dpkg(1) or dpkg --force-help, but most of the time the administrator will work directly with the aptitude or apt programs. It is, thus, necessary to know the syntax used to indicate the options to pass to the dpkg command (their command line interfaces are very similar).

# apt -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" full-upgrade

These options can also be stored directly in apt's configuration. To do so, simply write the following lines in the /etc/apt/apt.conf.d/local file:

Dpkg::Options {
  "--force-confdef";
  "--force-confold";
}

Dołączenie tej opcji w pliku konfiguracyjnym oznacza, że będzie ona także użyta w interfejsie graficznym takim jak aptitude.

The control archive frequently contains other files as well, like triggers, shlibs, or symbols. These files are well described in deb-triggers(5), deb-shlibs(5), and deb-symbols(5).

Triggers were introduced to reduce the amount of duplicated events during package installation, such as file registration or catalog/database update tasks. Packages can define their own or activate defined triggers. A more comprehensive documentation can be found in /usr/share/doc/dpkg/triggers.txt.gz.

The shlibs system is an older and simpler alternative to the symbols system for declaring dependencies for shared libraries. It defines the package name and version in which to find a specific SONAME-version of a shared library. The newer symbols system allows to define the dependency by tracking the symbols and when they have been introduced or changed in the library instead.