Package Splitting
Рекомендации по размещению файлов в пакетах
Очень часто в результате сборки одного исходного пакета получается набор каталогов и файлов, разных по функциональному назначению, порождаемым зависимостям и важности для функционирования основного ПО. В документе ALT specfile conventions даны общие правила оформления spec-файлов. Здесь дополнительно обсуждаются некоторые детали формирования пакетов в составе одного spec, которые, возможно, впоследствии войдут в официальный документ.
Резать толсто или тонко?
Помимо конвенций функционального деления на devel, doc, utils, lib%name и пр., часто возникает задача деления больших и/или сложных пакетов на компоненты с возможностью частичной установки. Это может быть ПО с семейством плагинов, расширений и т. п. Здесь существуют две крайности: слишком монолитные пакеты или россыпь слишком мелких пакетов по принципу «расщепим все, что расщепляется».
Тарболл как основа деления
Начинать следует с неразделенного набора файлов (после вышеупомянутого деления на конвенциональные пакеты), который чаще всего формирует основной пакет в spec. Как правило, в одном spec задается упаковка файлов, получаемых из одного исходного архива; если архивов несколько и добавочные исходники не являются дополнениями к основному дереву сборки, это может быть знаком того, что их нужно разнести по разным исходным пакетам (spec-ам).
Стереотипное использование
Общее правило: «то, что используется вместе, пакуется вместе». Полезны знания о ПО, его структуре и сценариях использования. К примеру, компоненты, обеспечивающие основную функциональность, остаются в основном пакете; добавочные пакеты формируются по признаку необходимости различным группам пользователей. Пример: mozilla и mozilla-mail.
Независимое использование
Если часть пакета может работать отдельно и используется другими пакетами (библиотека, плагин), то её имеет смысл отделить.
Разделение зависимостей
Если у некоторых опциональных компонентов существуют зависимости, не свойственные другим компонентам из упаковываемого набора, их нужно выделять в отдельные пакеты. Гранулярность зависимостей не стоит понимать слишком мелко: если несколько небольших компонентов зависит от разных пакетов, которые тем не менее обычно используются вместе (напр. latex и dvips), эти компоненты лучше объединить в один пакет.
Ссылка слонов
Если имеются несоразмерно большие компоненты, опциональные и ненужные большинству пользователей, их тоже следует выделить.
Крупные noarch-компоненты
Если не-noarch пакет содержит много noarch-содержимого (документация, данные, конфиги, скриптовые модули и т. д.), стоит вынести его в отдельный подпакет (с именем -data, например) и установить для него архитектуру noarch (FIXME: написать про фичу и её ограничения и залинковать сюда).
Документация и примеры
Документация и примеры обычно относятся сразу к нескольким вышеперечисленным категориям: они noarch, они могут занимать большой объём (это не относится к базовым файлам типа README, их лучше оставить в основном пакете), они нужны не всем пользователям (это относится в первую очередь к API-документации библиотек, к подробным руководствам и прочему и вряд ли относится к документации, доступной изнутри программы), а примеры ещё и могут иметь громоздкие зависимости. Пакеты с документацией желательно называть -doc (FIXME: -devel-doc для API-документации библиотек?), а пакеты с примерами — -examples. При этом указывать в пакете с документацией зависимость на основной пакет не стоит.
Экспериментальные части
Если какой-то функционал опционален и экспериментален одновременно, то его имеет смысл отделить, чтобы можно было пользоваться только стабильной частью.
Статические библиотеки
В документе ALT Linux сказано, что статические библиотеки нужно помещать в devel-static. На деле все несколько сложнее. Пакеты -devel-static были выделены из из -devel, чтобы вывести статические библиотеки, собирающиеся рядом с динамическими и одноименные им. В подавляющем большинстве случаев статические библиотеки никем не используются и -devel-static не создается по умолчанию. Однако в некоторых SDK существуют служебные статические библиотеки, не имеющие динамических аналогов. Их следует размещать в devel.