Структура APT пакета: разбираемся в строении пакета Debian

Источник: https://kali.training/topic/apt-package-reference/

В предыдущей статье «Как установить пакет, для которого отсутствует зависимость нужно версии» мы разобрали пакет .deb, внесли нужные нам изменения, собрали его обратно и установили. Мне это показалось весьма интересным, это может пригодиться в некоторых нестандартных ситуациях при установке некоторых пакетов не из системного репозитория. И я решил изучить эту тему поподробнее, благо отличный материал уже написан в Kali Linux Revealed Book.

Поэтому теперь пришло время занырнуть действительно глубоко в систему пакетов Debian и Kali. С этого места мы собираемся уйти за пределы инструментов и синтаксиса команд и больше сфокусироваться на «гайках и болтах» системы работы с пакетами. Этот закулисный вид поможет вам понять, как работает APT в своих основах и даст представление о том, как серьёзно рационализировать и настроить вашу систему Kali (здесь и далее говорится Kali, но имеется в виду также любой другой дистрибутив Linux на основе Debian). Вам необязательно заучивать весь материал из этого раздела, но в качестве материала для ознакомления и справочного материала он хорошо послужит в росте вашего мастерства по системе Kali Linux.

До сих пор вы взаимодействовали с данными пакета APT с помощью различных инструментов, предназначенных быть для него интерфейсом. Далее мы будем копать глубже, посмотрим во внутрь пакетов и рассмотрим внутреннюю метаинформацию (то есть информацию о другой информации), используемую инструментами управления пакетами.

Эта комбинация файлового архива и метаинформации явно видна по структуре файла .deb, который является просто архивов ar, объединяющим эти три файла:

ar t /var/cache/apt/archives/apt_1.4~beta1_amd64.deb
debian-binary 
control.tar.gz 
data.tar.xz

Файл debian-binary содержит один номер, описывающий формат архива:

ar p /var/cache/apt/archives/apt_1.4~beta1_amd64.deb debian-binary
2.0

Архив control.tar.gz содержит метаинформацию:

ar p /var/cache/apt/archives/apt_1.4~beta1_amd64.deb control.tar.gz | tar -tzf -
./ 
./conffiles 
./control 
./md5sums 
./postinst 
./postrm 
./preinst 
./prerm 
./shlibs 
./triggers

И наконец архив data.tar.xz (формат сжатия может различаться) содержит именно те файлы, которые устанавливаются в файловую систему:

ar p /var/cache/apt/archives/apt_1.4~beta1_amd64.deb data.tar.xz | tar -tJf -
./
./etc/
./etc/apt/
./etc/apt/apt.conf.d/
./etc/apt/apt.conf.d/01autoremove
./etc/apt/preferences.d/
./etc/apt/sources.list.d/
./etc/apt/trusted.gpg.d/
./etc/cron.daily/
./etc/cron.daily/apt-compat
./etc/kernel/
./etc/kernel/postinst.d/
./etc/kernel/postinst.d/apt-auto-removal
./etc/logrotate.d/
./etc/logrotate.d/apt
./lib/
./lib/systemd/
[...]

Помните, что в этом примере вы смотрите на .deb в архивном кэше APT и что ваш архив может содержать другие файлы с отличными от показанных номерами версий.

В этом разделе мы познакомимся с метаинформацией, содержащейся в каждом пакете и покажем, как это использовать.

1. Файл control

Мы начнём с обзора файла control, который содержится в архиве control.tar.gz. Файл control содержит самую жизненно важную информацию о пакете. Он использует структуру схожую с email заголовками и может быть просмотрен командой dpkg -I. Например, файл control для apt выглядит так:

dpkg -I apt_1.4~beta1_amd64.deb control
Package: apt
Version: 1.4~beta1
Architecture: amd64
Maintainer: APT Development Team<deity@lists.debian.org>
Installed-Size: 3478
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~)
Replaces: apt-utils (<< 1.3~exp2~)
Section: admin
Priority: important
Description: 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

В этом разделе мы пройдёмся по файлу control и объясним значение различных полей. Каждое из них даст вам дополнительное понимание системы работы с пакетами, даст вам больше контроля над тонкой настройкой, и даст знания, которые необходимы для решения проблем с которыми вы можете столкнуться при работе с пакетами. Пример такой проблемы и её исправление в статье «Как установить пакет, для которого отсутствует зависимость нужной версии».

1.1 Зависимости: поле Depends

Зависимости пакета определены в поле Depends в пакетном заголовке. Это список условий, которым должен удовлетворять пакет для правильной работы — эта информация используется такими инструментами как apt для установке требуемых библиотек в соответствующих версиях, удовлетворяющих зависимостям устанавливаемого пакета. Для каждой зависимости вы можете ограничить диапазон версий удовлетворяющих условию. Другими словами, можно выразить тот факт, что нужен пакет libc6 версии равной или большей чем «2.15» (записывается так «libc6 (>= 2.15)»). Операторами сравнения версий являются следующие:

• <<: меньше чем;
• <=: меньше чем или равно;
• =: равно (обратите внимание, что "2.6.1" не равно "2.6.1-1");
• >=: больше или равно;
• >>: больше чем.

В списке условий, которым должны удовлетворять зависимости, разделителем является запятая, интерпретируемая как логическое «И». В условиях вертикальная черта (труба) ("|") выражает логическое «ИЛИ» (это инклюзивное «ИЛИ», а не эксклюзивное «ЛИБО, ЛИБО»); то есть это включающее «ИЛИ», а не исключающее: подойдёт любой вариант или сразу оба, не требуется жёсткое условие «ТОЛЬКО ОДИН ИЗ». Оно имеет больший приоритет чем «И» и вы можете использовать его столько раз, сколько нужно. Таким образом, зависимость "(A OR B) AND C" записывается как A | B, C. В противоположность ей выражение "A OR (B AND C)" должно быть записано как "(A OR B) AND (A OR C)", но поскольку поле Depends не терпит круглых скобок, то изменён порядок приоритета логических операторов «ИЛИ» и «И». Поэтому выражение должно быть записано как A | B, A | C.

Итак, если вы знакомы с логикой и/или программированием, вы знаете, что всегда «И» имеет приоритет над «ИЛИ» — но как мы только что узнали, в случае с файлом control всё наоборот. Дополнительную информацию смотрите также на: https://www.debian.org/doc/debian-policy/ch-relationships.html

Система зависимостей это хороший механизм для гарантии работоспособности программы, но у него имеется и другое использование в мета-пакетах.

Метапакеты — это пустые пакеты, которые только описывают зависимости. Они облегчают установку совместной группы программ, предварительно выбранных сопровождающим метапакета; таким образом, команда apt install метапакет автоматически установит все эти программы, используя зависимости метапакета. Пакеты gnome, kde-full и kali-linux-full являются примерами метапакетов.

Смотрите также: Метапакеты Kali Linux

1.2 Pre-Depends — это более требовательные Depends

Предварительные зависимости, перечисленные в поле Pre-Depends заголовков пакета, дополняют обычные зависимости; их синтаксис идентичный. Обычная зависимость указывает, что она должна быть распакована и настроена до того, как конфигурация пакета объявит зависимость. Предварительная зависимость предусматривает, что данный пакет должен быть распакован и настроен до выполнения предустановочного скрипта пакета, объявляющего предварительную зависимость, то есть до его установки.

Предварительная зависимость очень требовательна для apt, потому что она добавляет строгое ограничение на порядок установки пакетов для установки. Как таковые, предварительные зависимости не приветствуются, если это не является абсолютно необходимым. Даже рекомендуется проконсультироваться с другими разработчиками по адресу debian-devel@lists.debian.org, прежде чем добавлять предварительную зависимость, так как обычно можно найти другое решение в качестве обходного пути.

1.3 Поля Recommends, Suggests, и Enhances

Поля Recommends (рекомендованные) и Suggests (предлагаемые) описывают зависимости, которые не являются обязательными. В первую очередь следует обратить внимание на рекомендуемые (Recommends) зависимости, они значительно улучшают функциональность, предлагаемую пакетом, но не являются обязательными для его работы. Предлагаемые (Suggests) зависимости, имеющие второстепенное значение, указывают на то, что некоторые пакеты могут дополнять и улучшать работу определённых утилит, но совершенно разумно устанавливать одни без других. Иногда в рекомендуемых зависимостях указывают просто пакеты с документацией и справкой.

Вам всегда следует устанавливать рекомендуемые пакеты, кроме тех ситуаций, когда вы точно знаете, почему они вам не нужны. И напротив, не нужно устанавливать предлагаемые зависимости, если вы не знаете, зачем они вам нужны.

Поле Enhances также описывает предложения, но в другом контексте. На самом деле это улучшение является улучшением для предложенного пакета, а не самого пакета, где прописано поле Enhances. Суть этого поля заключается в том, что можно добавить предложение в другой пакет без изменения соответствующего пакета. То есть поле Enhances как бы говорит «этот пакет является расширением для следующих перечисленных пакетов». Таким образом, все надстройки, плагины и другие расширения программы могут затем появиться в списке предложений, связанных с программным обеспечением. Хотя оно существует уже несколько лет, это последнее поле все ещё в значительной степени игнорируется такими программами, как apt или synaptic. Первоначальная цель состояла в том, чтобы позволить пакету типа xul-ext-adblock-plus (расширение Firefox) объявить Enhances: firefox, firefox-esr и, таким образом, появиться в списке предлагаемых пакетов, связанных с firefox и firefox-esr.

1.4 Конфликтующие пакеты: поле Conflicts

Поле Conflicts показывает когда пакет не может быть установлен одновременно с другим. Самой распространённой причиной этого является то, что оба пакета включают файлы с одинаковыми именами, предоставляют один и тот же сервис на одном и том же порту протокола управления передачей TCP.

Если пакет вызвал конфликт с уже установленным пакетом, dpkg откажется установить пакет, кроме когда новый пакет указывает, что он заменит установленный пакет, в этом случае dpkg предложит заменить старый пакет на новый. APT всегда следует вашим инструкциями: если вы выбрали установку нового пакета, он автоматически предложит удалить пакет, который создаёт проблему.

1.5 Несовместимости: поле Breaks

Поле Breaks имеет эффект схожий с полем Conflicts, но со специальным значением. Он сигнализирует, что установка пакета сломает другой пакет (или его определённую версию). В общем, эта несовместимость между двумя пакетами является приходящей (временной) и отношение Breaks относится к конкретным версиям.

Когда пакет ломает уже установленный пакет, dpkg откажется его устанавливать, а apt попытается решить эту проблему обновлением пакета, который может стать неисправным, на новую версию (исходя из предположения, что новая версия исправлена, и, следовательно, снова совместима).

Ситуация такого типа может возникнуть в случаях обновления без обратной совместимости: это тот случай, когда новая версия больше не работает со старой версией и вызывает сбой в другой программе без специальных условий. Поле Breaks помогает предотвратить подобные проблемы.

1.6 Представляемые пакеты: поле Provides

Это поле представляет очень интересную концепцию виртуального пакета. У него много ролей, но две из них имеют особое значение. Первая роль заключается в использовании виртуального пакета для связи с ним универсального сервиса (пакет предоставляет сервис). Вторая указывает, что пакет полностью заменяет другой и что для этой цели он также может удовлетворить зависимости, которые удовлетворяет другой. Таким образом, можно создать пакет замещения, не используя одно и то же имя пакета.

Метапакеты и Виртуальный пакет

Важно чётко отличать метапакеты от виртуальных пакетов. Первые являются реальными пакетами (включая настоящие файлы .deb), единственной целью которых является выражение зависимостей.

Виртуальные пакеты, однако, не существуют физически; они являются лишь средством идентификации реальных пакетов на основе общих логических критериев (например, предоставляемых услуг или совместимости со стандартной программой или уже существующим пакетом).

1.6.1 Предоставляемый сервис

Давайте обсудим первый случай более подробно с примером: все почтовые серверы, такие как postfix или sendmail, представлены виртуальным пакетом mail-transport-agent. Таким образом, любой пакет, который нуждается в функциональности этой службы (например, менеджер списков рассылки, такой как smartlist или sympa), в своих зависимостях просто заявляет, что ему требуется mail-transport-agent вместо указания большого, но неполного списка возможных решений. Более того, бесполезно устанавливать два почтовых сервера на одном компьютере, поэтому каждый из этих пакетов объявляет конфликт с виртуальным пакетом mail-transport-agent. Система игнорирует конфликт между пакетом и самим собой, но этот метод запрещает установку двух почтовых серверов рядом друг с другом.

1.6.2 Взаимозаменяемость с другим пакетом

Поле Provides также интересно, когда содержимое пакета включено в более крупный пакет. Например, модуль Perl libdigest-md5-perl был необязательным модулем в Perl 5.6 и был интегрирован как стандарт в Perl 5.8. Таким образом, в пакете perl с версии 5.8 объявлено Provides: libdigest-md5-perlso, эта запись означает, что если в системе имеется Perl 5.8 (или новее), то он выполняет и функции libdigest-md5-perlso, то есть libdigest-md5-perlso как будто бы тоже установлен. Сам libdigest-md5-perlpackage был удалён, когда удалялись старые версии Perl, так как он больше не имел никакого смысла.

Рисунок 1. Использование поля Provides чтобы не сломать зависимости:

Эта функция очень полезна, поскольку невозможно предвидеть превратности разработки, и необходимо иметь возможность приспособиться к переименованию и другой автоматической замене устаревшего программного обеспечения.

1.7 Замена файлов: поле Replaces

Поле Replaces указывает, что пакет содержит файлы, которые также присутствуют в другом пакете, но этот пакет имеет законное право заменить их. Без этой спецификации dpkg даёт сбой, заявляя, что он не может перезаписать файлы другого пакета (технически, это можно сделать принудительно с помощью параметра —force-overwrite, но это не считается стандартной операцией). Это позволяет выявить потенциальные проблемы и требует, чтобы сопровождающий изучил вопрос, прежде чем выбирать, добавлять ли такое поле.

Использование этого поля оправдано, когда имена пакетов меняются или когда пакет включён в другой. Это также происходит, когда сопровождающий решает распределить файлы по-разному среди различных двоичных пакетов, созданных из одного и того же исходного пакета: заменённый файл больше не принадлежит старому пакету, а только новому.

Если все файлы в установленном пакете были заменены, пакет считается удаленным. Наконец, это поле также побуждает dpkg удалять заменённый пакет в случае конфликта.

2. Скрипты конфигурирования

В дополнение к управляющему файлу архив control.tar.gz для каждого пакета Debian может содержать несколько скриптов (postinst, postrm, preinst, prerm), вызываемых dpkg на разных этапах обработки пакета.

Эти файлы представляют собой скрипты, выполняемые на различных этапах установки/удаления:

• preinst — выполняется перед установкой пакета
• postinst — выполняется после установки пакета
• prerm — выполняется перед удалением пакета
• postrm — выполняется после удаления пакета

Мы можем использовать dpkg -I, чтобы показать эти файлы, которые находятся в архиве пакета .deb:

dpkg -I /var/cache/apt/archives/zsh_5.3-1_amd64.deb | head
 new debian package, version 2.0.
 size 814486 bytes: control archive=2557 bytes.
     838 bytes,    20 lines      control
    3327 bytes,    43 lines      md5sums
     969 bytes,    41 lines   *  postinst             #!/bin/sh
     348 bytes,    20 lines   *  postrm               #!/bin/sh
     175 bytes,     5 lines   *  preinst              #!/bin/sh
     175 bytes,     5 lines   *  prerm                #!/bin/sh
 Package: zsh
 Version: 5.3-1

dpkg -I zsh_5.3-1_amd64.deb preinst
#!/bin/sh
set -e
# Automatically added by dh_installdeb
dpkg-maintscript-helper symlink_to_dir /usr/share/doc/zsh zsh-common 5.0.7-3 -- "$@"
# End automatically added section

Политика Debian подробно описывает каждый из этих файлов с указанием вызываемых скриптов и аргументов, которые они получают. Эти последовательности могут быть сложными, поскольку в случае сбоя в одном из скриптов dpkg попытается вернуться в удовлетворительное состояние, отменив установку или удалив сделанные изменения (насколько это возможно).

База данных dpkg

Вы можете просмотреть базу данных dpkg в файловой системе в /var/lib/dpkg/. Этот каталог содержит текущую запись всех пакетов, которые были установлены в системе. Все скрипты конфигурирования для установленных пакетов хранятся в каталоге /var/lib/dpkg/info/ в виде файла с префиксом имени пакета:

ls /var/lib/dpkg/info/zsh.*
/var/lib/dpkg/info/zsh.list /var/lib/dpkg/info/zsh.md5sums 
/var/lib/dpkg/info/zsh.postinst 
/var/lib/dpkg/info/zsh.postrm 
/var/lib/dpkg/info/zsh.preinst 
/var/lib/dpkg/info/zsh.prerm

В этот каталог также включён файл с расширением .list для каждого пакета, содержащий список файлов, принадлежащих этому пакету

head /var/lib/dpkg/info/zsh.list
/. 
/bin 
/bin/zsh 
/bin/zsh5 
/usr 
/usr/lib 
/usr/lib/x86_64-linux-gnu 
/usr/lib/x86_64-linux-gnu/zsh 
/usr/lib/x86_64-linux-gnu/zsh/5.2 
/usr/lib/x86_64-linux-gnu/zsh/5.2/zsh 
[...]

Файл /var/lib/dpkg/status содержит серию блоков данных (в формате запроса заголовков почты для комментариев, RFC 2822), описывающих состояние каждого пакета. Информация из файла control установленных пакетов также копируется туда.

more /var/lib/dpkg/status
Package: gnome-characters 
Status: install ok installed 
Priority: optional 
Section: gnome 
Installed-Size: 1785 
Maintainer: Debian GNOME Maintainers<pkg-gnome-maintainers@lists.alioth.debian.org> 
Architecture: amd64 
Version: 3.20.1-1 
[...]

Давайте обсудим файлы конфигурации и посмотрим, как они взаимодействуют. Как правило, сценарий preinst выполняется до установки пакета, а postinst следует за ней. Аналогично, prerm вызывается перед удалением пакета и postrm после. Обновление пакета эквивалентно удалению предыдущей версии и установке новой. Здесь невозможно подробно описать все возможные сценарии, но мы обсудим два наиболее распространённых: установку/обновление и удаление.

Эти последовательности могут быть довольно запутанными, но визуальное представление может помочь. Manoj Srivastava сделал диаграммы, объясняющие, как сценарии конфигурации вызываются dpkg. Подобные диаграммы были также разработаны проектом Debian Women; они немного проще для понимания, но менее полны.

Внимание: символические имена скриптов

Последовательности, описанные в этом разделе, вызывают скрипты конфигурации по определенным именам, таким как old-prerm или new-postinst. Это, соответственно, сценарий prerm, содержащийся в старой версии пакета (установленный до обновления), и сценарий postinst, содержащийся в новой версии (установленный обновлением).

2.1 Последовательность выполнения скриптов установки и обновления

Вот что происходит во время установки (или обновления):

1. Для обновления dpkg вызывает old-prerm upgrade new-version.
2. Тем не менее для обновления dpkg затем выполняет new-preinst upgrade old-version; для первой установки выполняется new-preinst install. Он может добавить старую версию в последний параметр, если пакет уже установлен и удалён (но не очищен, файлы конфигурации были сохранены).
3. Файлы нового пакета будут распакованы. Если файл уже существует, он заменяется, но резервная копия создаётся и временно сохраняется.
4. Для обновления dpkg выполняет old-postrm upgrade new-version.
5. dpkg обновляет все внутренние данные (список файлов, сценарии конфигурации и т. д.). И удаляет резервные копии заменённых файлов. Это точка невозврата: dpkg больше не имеет доступа ко всем элементам, необходимым для возврата в предыдущее состояние.
6. dpkg обновит файлы конфигурации, программа не может автоматически выполнить эту задачу, поэтому предложит вам решить, что делать со старыми и новыми конфигурационными файлами. Детали этой процедуры обсуждаются в разделе 3. «Контрольные суммы, Conffiles».
7. Наконец, dpkg настраивает пакет, выполняя команду new-postinst configure last-version-configured.

2.2 Удаление пакета

Вот что происходит во время удаления пакета.

1. dpkg вызывает prerm remove.
2. dpkg удаляет все файлы пакета, за исключением файлов конфигурации и скриптов конфигурации.
3. dpkg выполняет postrm remove. Все конфигурационные скрипты, кроме postrm, удалены. Если вы не использовали опцию очистки, процесс останавливается здесь.
4. Для полной очистки пакета (команда, введённая с помощью dpkg —purge или dpkg -P), также удаляются файлы конфигурации и определённое количество копий (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) и временные файлы; Затем dpkg выполняет postrm purge.

В некоторых случаях пакет может использовать debconf для запроса информации о конфигурации от вас: четыре скрипта, описанные выше, затем дополняются скриптом config, предназначенным для получения этой информации. Во время установки этот скрипт подробно определяет, какие вопросы будет задавать debconf. Ответы записываются в базу данных debconf для дальнейшего использования. Скрипт обычно выполняется apt перед установкой пакетов один за другим, чтобы сгруппировать все вопросы вместе в начале процесса. Скрипты до и после установки могут затем использовать эту информацию для работы в соответствии с вашими пожеланиями.

Инструмент debconf

Инструмент debconf был создан для решения повторяющейся проблемы в Debian. Все пакеты Debian, которые не могут работать без минимальной конфигурации, используются для того, чтобы задавать вопросы с вызовами команд echo и read в шелл скриптах postinst (и других подобных скриптах). Это приводило к тому, что установщик должен был присматривать за процессом обновления и отвечать на различные запросы конфигурации по мере их возникновения. Это ручное взаимодействие теперь почти полностью исключено благодаря debconf.

У инструмента debconf есть много интересных функций: он требует от разработчика определения взаимодействия с пользователем; позволяет переводить все отображаемые строки (все переводы хранятся в файле templates, описывающем взаимодействия); предоставляет различные интерфейсы для вопросов (текстовый режим, графический режим, неинтерактивный); и это позволяет создать центральную базу данных ответов для совместного использования одной конфигурации с несколькими компьютерами. Наиболее важной особенностью является то, что все вопросы могут быть представлены подряд, все сразу, до начала длительного процесса установки или обновления. Теперь вы можете заниматься своими делами, пока система самостоятельно выполняет установку, не нужно сидеть глядя на экран, ожидая появления вопросов.

3. Контрольные суммы, Conffiles

В дополнение к скриптам сопровождающего и управляющим данным, уже упомянутым в предыдущих разделах, архив control.tar.gz пакета Debian может содержать другие интересные файлы:

ar p /var/cache/apt/archives/bash_4.4-2_amd64.deb control.tar.gz | tar -tzf -
./
./conffiles
./control
./md5sums
./postinst
./postrm
./preinst
./prerm

Первый — md5sums — содержит контрольные суммы MD5 для всех файлов пакета. Его главное преимущество заключается в том, что он позволяет dpkg —verify проверять, были ли эти файлы изменены с момента их установки. Обратите внимание, что когда этот файл не существует, dpkg будет генерировать его динамически во время установки (и сохранять его в базе данных dpkg, как и другие контрольные файлы).

conffiles перечисляет файлы пакетов, которые должны обрабатываться как файлы конфигурации. Файлы конфигурации могут быть изменены администратором, и dpkg попытается сохранить эти изменения во время обновления пакета.

По сути, в этой ситуации dpkg ведёт себя максимально разумно: если стандартный файл конфигурации не изменился между двумя версиями, он ничего не делает. Однако, если файл изменился, он попытается обновить этот файл. Возможны два случая: либо администратор не трогал этот файл конфигурации, и в этом случае dpkg автоматически устанавливает новую версию; или файл был изменён, и в этом случае dpkg спрашивает администратора, какую версию он хочет использовать (старую с модификациями или новую, поставляемую с пакетом). Чтобы помочь в принятии этого решения, dpkg предлагает отобразить diff (различия), которые показывает разницу между двумя версиями. Если вы решите сохранить старую версию, новая будет сохранена в том же месте в файле с суффиксом .dpkg-dist. Если вы выбираете новую версию, старая сохраняется в файле с суффиксом .dpkg-old. Другое доступное действие состоит в кратковременном прерывании dpkg для редактирования файла и попытке восстановления соответствующих изменений (ранее идентифицированных с помощью diff).

dpkg обрабатывает обновления файла конфигурации, но при этом регулярно прерывает свою работу, чтобы запросить ввод у администратора. Это может быть трудоёмким и неудобным. К счастью, вы можете указать dpkg автоматически отвечать на эти запросы. Опция —force-confold сохраняет старую версию файла, в то время как —force-confnew будет использовать новую версию. Эти варианты соблюдаются, даже если файл не был изменён администратором, что лишь редко даёт желаемый эффект. Добавление параметра —force-confdef указывает dpkg самостоятельно решать, когда это возможно (другими словами, когда исходный файл конфигурации не был затронут), и использует —force-confnew или —force-confold для других случаев.

Эти параметры применяются к dpkg, но в большинстве случаев администратор будет работать напрямую с программами aptitude или apt. Таким образом, необходимо знать синтаксис, используемый для указания параметров, передаваемых команде dpkg (их интерфейсы командной строки очень похожи).

apt -o DPkg::options::="--force-confdef" -o DPkg::options::="--force-confold" full-upgrade

Эти параметры могут быть сохранены непосредственно в конфигурации apt. Для этого просто напишите следующую строку в файл /etc/apt/apt.conf.d/local:

DPkg::options { "--force-confdef"; "--force-confold"; }

Включение этой опции в файл конфигурации означает, что она также будет использоваться в графическом интерфейсе, таком как aptitude.

И наоборот, вы также можете заставить dpkg задавать вопросы о файле конфигурации. Опция —force-confask указывает dpkg отображать вопросы о файлах конфигурации даже в тех случаях, когда они обычно не нужны. Таким образом, при переустановке пакета с этой опцией dpkg снова задаст вопросы для всех файлов конфигурации, изменённых администратором. Это очень удобно, особенно для переустановки исходного файла конфигурации, если он был удалён, а другая копия недоступна: обычная переустановка не будет работать, поскольку dpkg рассматривает удаление как форму допустимого изменения и, таким образом, не устанавливает нужный файл конфигурации.