Что конвенции пакета там для человечности?
Трудно описать этот вопрос. Давайте посмотрим на пример:
Пакет blender зависит т.е. от blender-data. Я изучил оба пакета. blender содержит только приложение, .desktop файл и что-то как этот, в то время как blender-data также содержит значки приложения и так далее. Если я загружаю блендер с исходного веб-сайта, я не получаю пакета, но папки со всем, в чем я нуждаюсь.
Почему там блок данных для блендера? Есть ли больше тех конвенций? Какие пакеты там? Где я могу читать больше об этом? Я нашел большую информацию о том, как упаковать и внутренние детали, но ничто о соглашениях о присвоении имен и причине создать *-data пакеты.
2 ответа
Для ответа на вопрос здесь, я буду использовать LibreOffice в качестве примера (поскольку почти всем установили это). Если Вы находитесь на Lubuntu (который не имеет LibreOffice как стандартного офисного пакета программ для повышения производительности), и Вы устанавливаете LibreOffice, это - почти пустой пакет, хотя он имеет зависимости от пакета для Писателя, Calc, Основы, и т.д.
Зависимость от пакета является просто "указателем" на другой пакет. Иначе серверы в Каноническом (компания позади Ubuntu) быстро заполнились бы двойным, трижды, увеличились бы в четыре раза... пакеты, что все содержат те же файлы!
Пакет, что, сам по себе только содержит такие "указатели", знают как meta пакет.
Таким образом, пакет LibreOffice meta вытягивает в его отдельных пакетах (Например. calc), который вытягивает в их зависимостях, которые втягивают их, пока все зависимости не разрешены.
Можно однако установить только Calc без любого из других пакетов.
Для наблюдения этого в действии введите следующую команду в терминале:
apt-cache depends libreoffice-calc
И blender просто очень простой пример вышеупомянутого.
Еще некоторые детали:
Для некоторых пакетов вещи повреждаются в функциональные блоки: весьма распространено видеть названные пакеты: приложение, данные приложения, прикладные плагины, приложение-dev и некоторые другие, которыми каждый содержит соответственно само приложение, набор данных или данные для работы против, некоторые плагины или что-либо еще...
Для полного изложения:
Посетите Разработку управления пакетом Wiki.
В дополнение к ответу Fabby существует еще один вопрос для рассмотрения: зависимость от архитектуры содержания пакета.
Например, blender сама программа будет, очевидно, зависеть от архитектуры ОС - можно только работать amd64 двоичные файлы на amd64 Ose. Однако много данных не так зависит - файлы значков, переводы, программы, записанные на языках как Python или Java, например, могут быть тем же для всей архитектуры.
Таким образом первый шаг в оптимизации содержания пакета к разделению таких файлов в к общим пакетам, которые являются зависимостями архитектурно-зависимой версии. Общие файлы, обычно в пакетах с -data имейте архитектуру all. Двоичные и пакеты библиотеки имеют значения архитектуры amd64, i386, armhf, и т.д.
Это - на самом деле одна из Упаковочных Лучших практик, рекомендуемых Debian:
Весьма распространено иметь большой объем архитектурно-независимых данных, упакованных с программой. Например, звуковые файлы, набор значков, шаблонов обоев или других графических файлов. Если размер этих данных незначителен по сравнению с размером остальной части пакета, вероятно, лучше сохранить все это в единственном пакете.
Однако, если размер данных значителен, рассмотрите разделение его в отдельный, архитектурно-независимый пакет (
_all.deb). Путем выполнения этого Вы избегаете бесполезного дублирования тех же данных в одиннадцать или больше .debs, один на каждую архитектуру. В то время как это добавляет некоторые дополнительные издержки вPackagesфайлы, это сохраняет большое дисковое пространство на зеркалах Debian. Выделение архитектурно-независимых данных также уменьшает время обработки lintian (см. Раздел 2, “Инструменты линта пакета”) при выполнении по всему архиву 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