Какие соглашения о пакетах существуют для Ubuntu?

Трудно описать этот вопрос. Давайте посмотрим на пример:

Посылка blender зависит от blender-data, Я посмотрел в оба пакета. blender содержит только приложение, файл.desktop и что-то в этом роде, а blender-data также содержит значки приложений и так далее. Если я загружаю блендер с исходного сайта, я получаю не пакет, а папку со всем, что мне нужно.

Почему существует пакет данных для блендера? Есть ли еще такие конвенции? Какие есть пакеты? Где я могу прочитать больше об этом? Я нашел много информации о том, как упаковать и внутренние детали, но ничего о соглашениях об именах и причинах для создания *-data пакеты.

2 ответа

Решение

Чтобы ответить на ваш вопрос здесь, я буду использовать LibreOffice в качестве примера (так как почти у всех это установлено). Если вы работаете в Lubuntu (у которого нет LibreOffice в качестве стандартного пакета для офисной работы) и вы устанавливаете LibreOffice, это почти пустой пакет, хотя он имеет зависимости для Writer, Calc, Base и т. Д.

Зависимость пакета - это просто "указатель" на другой пакет. В противном случае серверы в Canonical (компания, занимающаяся Ubuntu) быстро заполнились бы двойными, тройными, четырехкратными... пакетами, которые содержат одинаковые файлы!

Пакет, который сам по себе содержит только такие "указатели", известен как метапакет.

Таким образом, метапакет LibreOffice тянет в отдельные пакеты (например, calc), который вытягивает их зависимости, которые вытягивают их до тех пор, пока все зависимости не будут разрешены.
Однако вы можете установить только Calc без каких-либо других пакетов.

Чтобы увидеть это в действии, введите следующую команду в терминале:

apt-cache depends libreoffice-calc

А также blender это просто очень простой пример вышесказанного.

Еще несколько деталей:

Для некоторых пакетов вещи разбиты на функциональные блоки: нередко можно увидеть пакеты, называемые: application, application-data, application-plugins, application-dev и некоторые другие, каждый из которых содержит соответственно само приложение, набор данных или данные для работать против, некоторые плагины, или что-нибудь еще...

Для полной информации:

Посетите Wiki управления пакетами управления.

В дополнение к ответу Фабби, есть еще один момент для рассмотрения: архитектурная зависимость содержимого пакета.

Например, blender Сама программа, очевидно, будет зависеть от архитектуры ОС - запускать можно только amd64 двоичные файлы на amd64 Операционки. Однако большая часть данных не так зависима - файлы значков, переводы, программы, написанные на таких языках, как, например, Python или Java, могут быть одинаковыми для всех архитектур.

Таким образом, первым шагом в оптимизации содержимого пакета является разбиение таких файлов на общие пакеты, которые являются зависимостями конкретной архитектуры. Общие файлы, как правило, в пакетах с -data иметь архитектуру all, Двоичные и библиотечные пакеты имеют значения архитектуры amd64, i386, armhf, так далее.

На самом деле это одна из рекомендаций по упаковке, рекомендованная Debian:

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

Однако, если размер данных значительный, рассмотрите возможность его разделения на отдельный, независимый от архитектуры пакет (_all.deb). Делая это, вы избегаете ненужного дублирования одних и тех же данных в одиннадцать или более.debs, по одному на каждую архитектуру. Хотя это добавляет некоторые дополнительные издержки в Packages файлы, это экономит много дискового пространства на зеркалах Debian. Разделение данных, не зависящих от архитектуры, также сокращает время обработки lintian (см. Раздел A.2, "Инструменты пакета lint") при запуске по всему архиву Debian.

Такие независимые от архитектуры файлы часто входят в /usr/share - На самом деле, это нарушение политики, когда в этом дереве каталогов находятся файлы, зависящие от архитектуры.

Тогда естественным образом появляется способ организации вещей:

all
├── doc      # man pages, documentation in other formats
├── icons
├── themes
├── translations
└── etc.
arch
├── bin      # binaries
├── dbg      # binaries with debug symbols
├── lib      # shared library files
└── lib-dev  # header files and other shared library files for development
Другие вопросы по тегам