Package Splitting: различия между версиями

Материал из ALT Linux Wiki
(Import from freesource.info)
 
 
(не показано 8 промежуточных версий 7 участников)
Строка 1: Строка 1:
[[Category:Policy]]
[[Категория:Devel]]
{{MovedFromFreesourceInfo|AltLinux/Policy/PackageSplitting}}
{{DraftPolicy
|responsible=none
|discussion_link=none
|discussion_since=none
}}


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


Очень часто в результате сборки одного исходного пакета получается набор каталогов и файлов, разных по функциональному назначению, порождаемым зависимостям и важности для функционирования основного ПО.
Очень часто в результате сборки одного исходного пакета получается набор каталогов и файлов, разных по функциональному назначению, порождаемым зависимостям и важности для функционирования основного ПО.
В документе [http://docs.altlinux.ru/beta/alt/ch01s01.html ALT specfile conventions] даны общие правила оформления spec-файлов. Здесь дополнительно обсуждаются некоторые детали формирования пакетов в составе одного spec, которые, возможно, впоследствии войдут в официальный документ.
В документе [http://docs.altlinux.org/archive/2.2/master/devel-html/ch01.html ALT specfile conventions] даны общие правила оформления spec-файлов. Здесь дополнительно обсуждаются некоторые детали формирования пакетов в составе одного spec, которые, возможно, впоследствии войдут в официальный документ.


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


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


==== Тарболл как основа деления ====
==== Тарболл как основа деления ====
Строка 17: Строка 21:
==== Стереотипное использование ====
==== Стереотипное использование ====


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


==== Независимое использование ====
==== Независимое использование ====
Строка 30: Строка 34:


Если имеются несоразмерно большие компоненты, опциональные и ненужные большинству пользователей, их тоже следует выделить.
Если имеются несоразмерно большие компоненты, опциональные и ненужные большинству пользователей, их тоже следует выделить.
==== Крупные <tt>noarch</tt>-компоненты ====
Если не-<tt>noarch</tt> пакет содержит много <tt>noarch</tt>-содержимого (документация, данные, конфиги, скриптовые модули и т. д.), стоит вынести его в отдельный подпакет (с именем <tt>-data</tt>, например) и установить для него архитектуру <tt>noarch</tt> (FIXME: написать про фичу и её ограничения и залинковать сюда).
==== Документация и примеры ====
Документация и примеры обычно относятся сразу к нескольким вышеперечисленным категориям: они noarch, они могут занимать большой объём (это не относится к базовым файлам типа <tt>README</tt>, их лучше оставить в основном пакете), они нужны не всем пользователям (это относится в первую очередь к API-документации библиотек, к подробным руководствам и прочему и вряд ли относится к документации, доступной изнутри программы), а примеры ещё и могут иметь громоздкие зависимости. Пакеты с документацией желательно называть <tt>-doc</tt> (FIXME: <tt>[http://sisyphus.ru/find.shtml?request=-devel-doc -devel-doc]</tt> для API-документации библиотек?), а пакеты с примерами — <tt>-examples</tt>. При этом указывать в пакете с документацией зависимость на основной пакет не стоит.


==== Экспериментальные части ====
==== Экспериментальные части ====
Строка 38: Строка 50:


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

Текущая версия от 07:52, 30 марта 2012

Stub.png
Черновик политики Sisyphus
Автор(ы) — none
[none Обсуждение в devel@]
Обсуждается с none


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

Очень часто в результате сборки одного исходного пакета получается набор каталогов и файлов, разных по функциональному назначению, порождаемым зависимостям и важности для функционирования основного ПО. В документе 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.