Вход:  Пароль:  
FreeSource: AltLinux/Policy/PackageSplitting ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Эта страница была перенесена на altlinux.org. Текст на freesource.info заморожен.

Рекомендации по размещению файлов в пакетах


Очень часто в результате сборки одного исходного пакета получается набор каталогов и файлов, разных по функциональному назначению, порождаемым зависимостям и важности для функционирования основного ПО.
В документе ALT specfile conventions даны общие правила оформления spec-файлов. Здесь дополнительно обсуждаются некоторые детали формирования пакетов в составе одного spec, которые, возможно, впоследствии войдут в официальный документ.

Резать толсто или тонко?


Помимо конвенций функционального деления на devel, doc, utils, lib%name и пр., часто возникает задача деления больших и/или сложных пакетов на компоненты с возможностью частичной установки. Это может быть ПО с семейством плагинов, расширений и т.п. Здесь существуют две крайности: слишком монолитные пакеты или россыпь слишком мелких пакетов по принципу «расщепим все, что расщепляется».

Тарболл как основа деления


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

Стереотипное использование


Общее правило: «то, что используется вместе, пакуется вместе». Полезны знания о ПО, его структуре и сценариях использования. К примеру, компоненты, обеспечивающие основную функциональность, остаются в основном пакете; добавочные пакеты формируются по признаку необходимости различным группам пользователей. Пример: mozilla и mozilla-mail.

Независимое использование


Если часть пакета может работать отдельно и используется другими пакетами (библиотека, плагин), то её имеет смысл отделить.

Разделение зависимостей


Если у некоторых опциональных компонентов существуют зависимости, не свойственные другим компонентам из упаковываемого набора, их нужно выделять в отдельные пакеты. Гранулярность зависимостей не стоит понимать слишком мелко: если несколько небольших компонентов зависит от разных пакетов, которые тем не менее обычно используются вместе (напр. latex и dvips), эти компоненты лучше объединить в один пакет.

Ссылка слонов


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

Экспериментальные части


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

Статические библиотеки


В документе ALT Linux сказано, что статические библиотеки нужно помещать в devel-static.
На деле все несколько сложнее. Пакеты -devel-static были выделены из из -devel, чтобы вывести статические библиотеки, собирающиеся рядом с динамическими и одноименные им. В подавляющем большинстве случаев статические библиотеки никем не используются и -devel-static не создается по умолчанию. Однако в некоторых SDK существуют служебные статические библиотеки, не имеющие динамических аналогов. Их следует размещать в devel.


Страницы, ссылающиеся на данную: AltLinux/Policy
Altlinux/Policy


 
Файлов нет. [Показать файлы/форму]
Комментарии [Скрыть комментарии/форму]