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.