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

Материал из ALT Linux Wiki
(Import from freesource.info)
 
(перенос в категорию Devel)
Строка 1: Строка 1:
[[Category:Policy]]
[[Категория:Devel]]
{{MovedFromFreesourceInfo|AltLinux/Policy/PackageSplitting}}
{{MovedFromFreesourceInfo|AltLinux/Policy/PackageSplitting}}


Строка 9: Строка 9:
=== Резать толсто или тонко? ===
=== Резать толсто или тонко? ===


Помимо конвенций функционального деления на <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: Строка 17:
==== Стереотипное использование ====
==== Стереотипное использование ====


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


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

Версия от 15:41, 20 сентября 2008

Freesource-logo.png Blue Glass Arrow.svg MediaWiki logo.png
Эта страница была перемещена с 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.