Packaging/NamingGuidelines/ru

Руководство по наименованию и версионизации пакетов

Автор оригинала: Tom 'spot' Callaway

Общий набор символов для наименования пакетов

Поскольку Fedora - это международное сообщество, то в целях обеспечения согласованности и удобства пользования при наименовани пакетов необходимо использование общего набора символов.

Для этого все пакеты Fedora должны именоваться с использованием только перечисленных ниже ASCII-символов:

abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789-._+

При этом необходимо обратить внимание на Разделители для учета дополнительных ограничений по использованию символов -._+ в именах пакетов.

Общие правила наименования

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

Кроме того, возможна ситуация, при которой имя, используемое источником, не соответствует Общему набору символов. В этом случае необходимо ознакомиться с правилами транслитерации из подраздела Если имя источника не соответствует установленному набору символов.

Разделители

При наименовании пакетов Fedora ответственные за сопровождение данных пакетов должны использовать символ дефиса '-' в качестве разделителя частей имени. При этом использование символов нижнего подчеркивания '_', знака сложения '+' и точки '.' в качестве разделителей НЕ допускается. В то же время для пакетов, содержащих библиотеки совместимости, в номерах версий, используемых как часть имен этих пакетов, пропуск или замена символа точки '.' на символ дефиса '-' необязательны.

Существет несколько исключений относительно использования символа нижнего подчеркивания '_' в качестве разделителя. Исключение составляют:

• пакеты дополнений для httpd, pam и SDL, см. " Пакеты дополнений (httpd, pam и SDL) "
• пакеты, содержащие в составе своего имени название локализации, см. " Пакеты дополнений (локализации) "
• пакеты, имя источника которых изначально содержало символ нижнего подчеркивания; примерами подобных пакетов являются:

arptables_jf
dhcpv6_client
java_cup
knm_new
libart_lgpl
lm_sensors
microcode_ctl
nss_db
nss_ldap
sg3_utils
tcp_wrappers

Любые сомнения, возникшие при выборе имени, можно прояснить, задав вопрос на fedora-devel-list.

Если имя источника не соответствует установленному набору символов

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

В том (и только в том) случае, если автор источника недоступен, не может или не желает предоставить транслитерированное имя, ответственный за сопровождение пакета в Fedora должен либо осуществить транслитерацию самостоятельно, либо отказаться от включения программного обеспечения из данного источника в состав Fedora.

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

Дополнительные предоставляемые имена

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

Несовместимые имена пакетов

Несовместимыми называются совпадающие имена пакетов или имена, различающиеся только регистром символов. Появление несовместимых имен пакетов недопустимо. Подробнее см. Packaging:Conflicts#Conflicting Package Names.

Несколько пакетов с общим базовым именем

Иногда, в силу тех или иных причин, бывает полезно обеспечить возможность одновременной установки в Fedora нескольких версий одного и того же пакета. Это, в свою очередь, требует привидения имен таких пакетов в соответствие с вышеизложенным требованием совместимости. Для обеспечения этого один из пакетов продолжает использовать неизмененное базовое имя, а имена остальных пакетов должны быть модифицированы таким образом, чтобы включать информацию об их соответствующих версииях.

Пример:
Пакет openssl часто включается в Fedora в составе нескольких версий для обеспечения обратной совместимости.
Более старшая из версий пакета openssl имеет в качестве значения поля имени Name: openssl
Предыдущая версия пакета openssl имеет в качестве значения поля имени Name: openssl096b
Следует обратить внимание на отсутствие символов-разделителей в данной ситуации. Вместо этого версия пакета, из которой предварительно были удалены символы точки (что в общем случае не является обязательным), была присоединена непосредственно к его базовому имени.

Включение версии ОС в имена пакетов документации

Имена пакетов документации (утвержденных проектом документирования Fedora Documentation Project) могут включать в себя номер версии ОС для обеспечения возможности одновременной установки нескольких версий в случаях, когда содержащаяся в них документация является специфичной для соответствующего выпуска Fedora и имеется определенный смысл в такой их установке.

Имя spec-файла

Spec-файл должен иметь имя, соответствующее схеме %{name}.spec. Это ускорит поиск конкретного spec-файла при установке src.rpm.

Пример:

Если файл пакета имеет имя foo-1.0.0-1.src.rpm, то spec-файл должен иметь имя foo.spec.

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

Версионизация пакета

В Fedora должна обеспечитваться возможность выполнения обновлений пакетов как в рамках текущего выпуска, так и при переходе к следующему выпуску дистрибутива. Для этого необходимо, чтобы пакеты, относящиеся к более новому выпуску, имели значение Epoch:Version-Release (EVR), большее или равное аналогичному значению для этих же пакетов из более ранних выпусков. Примером реализации этого правила будут пакеты foo-1.0-1.fc13 из выпуска Fedora-13 и foo-1.0-2.fc14 из Fedora-14. В данном случае пакет из выпуска Fedora-14 имеет более старшую версию и будет корректно обновлять пакет из Fedora-13.

Более сложный пример. Fedora-13 включает пакет foo-1.0-1.fc13, Fedora-14 - пакет foo-1.0-2.fc14. Для пакета foo из Fedora-13 выходит обновление: foo-1.0.1-1.fc13. Данное обновление имеет значение EVR, которое старше, чем у исходного пакета, так что в пределах Fedora-13 противоречий нет. В то же время, это же самое значение является более старшим, чем значение EVR для пакета из Fedora-14, и следовательно, для обеспечения возможности перехода от Fedora-13 к Fedora-14, требуется дополнительно выпустить обновленный пакет для Fedora-14, например, такой: foo-1.0.1-1.fc14. Наличие этого пакета обновления позволит корректно выполнить обновление пакета foo при переходе от Fedora-13 с включенными обновлениями к Fedora-14 также с включенными обновлениями.

Единственным моментом, когда допустимо временное нарушение перехода между выпусками, является переход от некоторого выпуска Fedora к rawhide. Разрешается временное существование пакета с большим значением EVR в составе выпусков Fedora относительно аналогичного пакета из rawhide в случае, когда требуется срочно выпустить корректирующее обновление пакета для этих выпусков Fedora (например, для устранения уязвимости, влияющей на безопасность), но пакет с обновлением еще не был собран в rawhide (например, по причине изменений в некоторой библиотеке, от которой зависит пакет, учет которых потребует дополнительных усилий по портированию). При этом необходимые изменения должны быть загружены в систему управления исходными кодами (УИК, SCM) Fedora для ветви rawhide, а выполнение требуемой для восстановления перехода на rawhide сборки пакета должно стать приоритетной задачей.

В пакетах rpm старшинство версий определяется на основе значений, хранящихся в тегах периода Epoch, версии Version и выпуска Release. В последующих разделах приводится описание правил по использованию перечисленных тегов, гарантирующих последовательное увеличение значения EVR.

Тег номера версии Version

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

Существует четыре случая, когда значение версии может содержать символы, отличные от цифр:

• Предварительный (pre-release) пакет - пакет, выпущенный до выхода финальной (final) версии. Типичными примерами нечисловых тегов в версиях таких пакетов являются "alpha", "beta", "rc", "cvs". Сохранение подобных тегов в составе номера версии является недопустимым, поэтому они переносятся поле Release. Подробности см. Нечисловая часть номера версии в номере выпуска

• Доработанный (post-release) пакет - пакет, выпущенный после выхода финальной версии. Такие пакеты имеют одинаковые значения числовой части номера (финальной) версии, но дополнительно содержат нечисловой идентификатор. Подробности см. Нечисловая часть номера версии в номере выпуска

• Пакет со снимком (snapshot) - пакет, содержащий снимок, извлеченный из системы контроля версий (СКВ) типа cvs или subversion. Такие пакеты могут быть как предварительными, так и доработанными. Подробности см. Нечисловая часть номера версии в номере выпуска

• Пакет Fedora, полученный из пакета JPackage. Для пакетов, получаемых из JPackage RPMS, применяются специальные правила. Подробности см. JPackagePolicy

Отказ от использования символа тильды "~"
rpm версии 4.10 и новее поддерживает использование символа тильды в стиле Debian для отделения части версии, которая в дальнейшем при выполнении каких-либо классификаций будет использована в первую очередь. На настоящий момент такое использование не разрешается по следующим причинам:

• отсутствие объективной необходимости при соблюдении изложенных ниже правил для тега номера выпуска
• отсутствие поддержки в rpm из текущих выпусков Fedora
• необходимость введения дополнительного специального символа для получения возможностей, достижимых другим способом

Тег номера выпуска Release

Ранее в Fedora.us использовалось значение 0.fdr в качестве префикса в номере выпуска для обозначения принадлежности пакетов к Fedora.us. В Fedora такая маркировка репозитория не является необходимой и применяться не должна. Номер выпуска (обозначаемый также как "vepoch" в старой документации) - это маркер, используемый сопровождающим пакет для включения последовательного номера сборки, начинающегося с 1. Если осуществлено незначительное изменение пакета (исправлен spec-файл, добавлен/удален patch-файл) или пакет был пересобран с использованием более новых заголовочных файлов или библиотек, то значение номера выпуска должно быть увеличено. Если же выполняется крупное изменение (формируется пакет с новой версией включаемого в его состав ПО), то в этом случае значение номера версии пакета должно быть изменено так чтобы отражать новый номер версии исходного ПО, а значение номера выпуска должно быть установлено в 1.

Нечисловая часть номера версии в номере выпуска

Существует три случая, при которых нечисловая часть номера версии перемещается в поле номера выпуска:

• Пакет содержит снимок из СКВ
• Пакет является предварительным
• Пакет является доработанный

Пакеты, содержащие снимки

Пакет со снимком должен хранить сведения о нахождении источника, из которого был извлечен данный снимок, а также иную информацию, необходимую для доступа к снимку средствами rpm. Далее в текущем подразделе подобная информация о снимке будет обозначаться как %{checkout}.

%{checkout} состоит из даты извлечения снимка в формате ГГГГММДД, короткой (2-5 символов) строки, идентифицирующей тип СКВ или содержащей признак снимка и до 13 необязательных алфавитно-цифровых символов (ASCII), которые позволяют определить версию снимка в СКВ.

Так например, для снимка, извлеченного из репозитория git 2 января 2011 года и имеющего значение хеш-свертки 9e88d7e9efb1bcd5b41a408037bb7cfd47220a64, строка %{checkout} может быть одной из следующих:

20110102snap
20110102git
20110102git9e88d7e

Если пакет со снимком является предварительным, то в этом случае необходимо следовать указаниям, приведенным в подразделе Предварительные пакеты со снимками, используя в качестве значения %{checkout} один из приведенных выше вариантов. (Например, для пакета kismet-0.0.3.20040204svn, значением %{checkout} будет 20040204svn.)

Если пакет со снимком является доработанным, то необходимо следовать указаниям, приведенным в подразделе Доработанные пакеты. При этом значение, обозначаемое как %{posttag}, является одним из приведенных выше вариантов значения %{checkout}.

Примеры (доработанный пает, cvs):

kismet-1.0-1 (официальный выпуск пакета kismet версии 1.0)
kismet-1.0-2 (сборка, включающая исправление для версии 1.0)
kismet-1.0-3.20050515cvs (доработанный пакет со снимком из cvs)
kismet-1.0-4.20050515cvs (исправление для доработанного пакета со снимком из cvs)
kismet-1.0-5.20050517cvs (доработанный пакет с новым снимком из cvs, значение %{X} увеличено)

Предварительные пакеты

Пакеты предварительных выпусков с нечисловой версионизацией могу представлять некоторые сложности и должны обрабатываться с осторожностью. Существуют случаи, при которых версия ПО, используемая источником, не является исключительно числовой, а содержит еще и буквы. Чаще всего в номерах версий встречаются такие теги как alpha, beta, rc, а также отдельные буквы, например, a или b, обозначающие, что текущая версия не является окончательной. Поскольку использование букв в теге номера версии недопустимо, для хранения нечисловой части номера версии используется тег номера выпуска.

Значение тега номера выпуска для предварительных пакетов: 0.%{X}.%{alphatag}

Здесь значение %{X} - это последовательный номер выпуска, а %{alphatag} - строка, содержащая нечисловую часть номера версии. В данном случае символ точки '.' используется как разделитель для значений последовательного номера выпуска и нечисловой части номера версии. Никаких других записей в поле Release быть не должно. Данное требование необходимо для предотвращения появления номеров выпуска вида "3jpp_2fc.42-spotwashere".

Пример (предварительный пакет mozilla)

Исходный архив	Описание
mozilla-1.4a.tar.gz	(предварительный выпуск mozilla, версия 1.4a)
mozilla-1.4.tar.gz	(окончательный выпуск, версии 1.4)
Значение тега номера выпуска	Пояснения
mozilla-1.4-0.1.a	(значение %{name}-%{version}-%{release}, преобразованное для Fedora)
mozilla-1.4-1	(значение %{name}-%{version}-%{release} для окончательного выпуска 1.4 в составе Fedora)

Пример (предварительный пакет alsa-lib)

Исходный архив	Описание
alsa-lib-0.9.2beta1.tar.gz	(beta-выпуск alsa-lib, версия 0.9.2beta1)
Значение тега номера выпуска	Пояснения
alsa-lib-0.9.2-0.1.beta1	(значение %{name}-%{version}-%{release}, преобразованное для Fedora)
alsa-lib-0.9.2-0.2.beta1	(значение %{name}-%{version}-%{release} для очередного выпуска пакета Fedora. Префиксный 0 сохраняется.)

Пример (предварительный пакет kismet со снимком из svn)

Значение тега номера выпуска	Пояснения
kismet-0-0.1.20040110svn	(предварительный пакет kismet со снимком из svn)
kismet-0-0.2.20040110svn	(исправление для предыдущего пакета)
kismet-0-0.3.20040204svn	(новый снимок из svn, значение %{X} увеличено)
kismet-1.0-1	(пакет с финальной версией kismet 1.0)

Пример последовательности обновлений (mozilla)

Значение тега номера выпуска	Пояснения
mozilla-1.4-0.1.a	(пакет Fedora для версии 1.4a, см. выше)
mozilla-1.4-0.2.a	(первое исправление для 1.4a)
mozilla-1.4-0.3.a	(следующее исправление для 1.4a)
mozilla-1.4-0.4.b	(первичная сборка после обновления до версии 1.4b)
mozilla-1.4-0.5.b	(первое исправление для 1.4b)
mozilla-1.4-1	(финальная версия 1.4 и нормальная индексация)
mozilla-1.4-2	(первое исправление для финальной версии 1.4)

Пример последовательности обновлений (alsa-lib)

Значение тега номера выпуска	Пояснения
alsa-lib-0.9.2-0.1.beta1	(пакет Fedora для версии 0.9.2beta1, см выше)
alsa-lib-0.9.2-0.2.beta1	(первое исправление для 0.9.2beta1)
alsa-lib-0.9.2-0.3.beta2	(обновление до версии 0.9.2beta2)
alsa-lib-0.9.2-0.4.beta3	(обновление до версии 0.9.2beta3)
alsa-lib-0.9.2-0.5.beta3	(первое исправление для 0.9.2beta3)
alsa-lib-0.9.2-0.6.rc1	(обновление до версии 0.9.2rc1)
alsa-lib-0.9.2-0.7.rc2	(обновление до версии 0.9.2rc2)
alsa-lib-0.9.2-1	(финальная версия 0.9.2 и нормальная индексация)
alsa-lib-0.9.2-2	(первое исправление для финальной версии 0.9.2)

Доработанные пакеты

Как и пакеты предварительных выпусков, доработанные пакеты с нечисловой версионизацией также могу представлять сложности и также должны обрабатываться с осторожностью. Такие пакеты обобщенно могут быть подразделены на две категории:

• Пакеты с простыми упорядоченными значениями версий. Обычно выпуск таких пакетов обусловлен оперативным исправлением ошибок, например, openssl-0.9.6b или gkrellm-2.1.7a. По мере выхода следующей версии либо корректно увеличивается нечисловая часть значения (например, openssl-0.9.6c), либо увеличивается числовая часть значения, а нечисловая при этом ликвидируется (openssl-0.9.7). В таком случае допустимо наличие символов, отличных от цифр, в значении поля Version.
• Пакеты, включающие ПО, для версионизации которого источник использовал осмысленные человекочитаемые значения вместо значений, подходящих для обработки машиной. Например, GA1, CR2, PR3. В такиих случаях нечисловая часть номера версии перемещается в поле Release с использованием следующего формата: %{X}.%{posttag}

В приведенном выше формате значение %{X} является последовательным номером выпуска, а значение %{posttag} - это строка, перемещенная из номера версии. В данном случае символ точки '.' используется в качестве разделителя последовательного номера выпуска и нечисловой части номера версии. Никаких других записей в поле Release быть не должно.

Пример (доработанный пакет в комплексном варианте):

foo-1.1.0-0.1.BETA (предварительный выпуск, первая beta-версия)
foo-1.1.0-0.2.BETA1 (предварительный выпуск, вторая beta-версия)
foo-1.1.0-0.3.BETA2 (предварительный выпуск, третья beta-версия)
foo-1.1.0-0.4.CR1 (предварительный выпуск, кандидат 1)
foo-1.1.0-0.5.CR2 (предварительный выпуск, кандидат 2)
foo-1.1.0-1 (финальный выпуск)
foo-1.1.0-2.GA1 (доработанный выпуск, GA1)
foo-1.1.0-3.CP1 (доработанный выпуск, CP1, после GA1)
foo-1.1.0-4.CP2 (доработанный выпуск, CP2, после CP1)
foo-1.1.0-5.SP1 (доработанный выпуск, SP1, после CP2)
foo-1.1.0-6.SP1_CP1 (доработанный выпуск, SP1_CP1, после SP1)

Использование приведенной схемы для формирования пакетов, включающих доработанное ПО, должно выполняться с особой внимательностью в целях обеспечения правильного порядка их выхода. Возможно также, что при этом для установления гарантированного старшинства версии текущего пакета по отношению к предыдущему может потребоваться использование значения номра периода Epoch. В подобных случаях ответственному за сопровождение пакета следует попытаться связаться с автором источника и убедить его использовать более приемлимые значения для доработанных версий.

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

Использование тега дистрибутива %{?dist}

Если один и тот же spec-файл должен использоваться для сборки пакета для нескольких дистрибутивов, то в этом случае в поле номера выпуска Release может дополнительно включаться значение тега %{?dist}. Для подробностей по надлежащему использованию тега см. Packaging:DistTag.

Незначительные исправления старых веток

В некоторых случаях может возникнуть ситуация, при которой для пакета из состава одной из старых веток дистрибутива может потребоваться исправление в то время как более новые ветви в подобном исправлении не нуждаются. Например, пакет foo = 1.0-1%{?dist} входит в состав веток FC-4 и FC-5, и исправление необходимо только для FC-4. Типичным дествием при этом будет увеличить значение последовательного номера выпуска пакета для обеих веток, чтобы сохранить отношение FC-4 < FC-5, но это приведет к нецелевому расходованию времени и энергии, которые будут затрачены на сборку пакета для новой ветки, не требующей такой сборки.

В таком случае, вместо обычного увеличения последовательного номера, в конец номера выпуска для сборки, включаемой в состав ветви, где требуется изменение, может дописываться дополнительное число (с префиксной точкой). Пример:

Release: 1%{?dist}

Release: 1%{?dist}.1

Это позволит собрать пакет foo-1.0-1.fc4.1, который по-прежнему будет младшим по отношению к пакету foo-1.0-1.fc5 из ветви FC-5.

В последствии, при наличии такой необходимости последнее значение (номер незначительного исправления выпуска) может увеличиваться независимо для каждой из веток.
Существенным моментом данной схемы является то, что ее применение допустимо ТОЛЬКО при использовании тега дистрибутива в в поле Release.

ВНИМАНИЕ! Во всех случаях отношение старшинства между пакетами должно оставаться таковым, чтобы сохранялась возможность выполнения обновления пакетов из более старых веток на пакеты из более новых веток дистрибутива. Т.е. всегда должно быть FC-4 < FC-5 < FC-6 и т.д. В составе пакета rpmdevtools имеется утилита rpmdev-vercmp, которая запрашивает и затем сравнивает два набора параметров, включающих значения номера периода, версии и выпуска (Epoch, Version, Release), выводя отношение старшинства между ними в соответствии с правилами сравнения rpm.

Различимость регистра

При формировании пакетов Fedora ответственный за сопровождение должен руководствоваться наиболее логичными суждениями при выборе имени пакета. При этом, до тех пор, пока различимость регистра не является обязательным требованием его использование должно быть обусловлено конкретной необходимостью. В данном вопросе также следует учитывать пожелания авторов источника. Например, если разработанному ПО авторами присвоено имя "ORBit", то для формируемого из этого ПО пакета вместо имени "orbit" должно назначаться оригинальное имя "ORBit". В то же время, если авторы не настаивают на каком-либо конкретном варианте написания, то при наименовании пакета необходимо использовать символы нижнего региситра.

Исключением из правила являются пакеты, содержащие модули perl. Для таких пакетов названия CPAN Group и Type должны записываться с заглавной буквы как имена собственные. (Подробности см. Пакеты дополнений (модули perl) )

Переименование/замещение существующих пакетов

См.: Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages

Субпакеты документации

Файлы объемной документации должны размещаться в отдельном субпакете. Имя такого пакета должно соответствовать формату %{name}-doc. Определение понятия объемности остается на усмотрение ответственного за сопровождение пакета, оно может основываться как на размере, так и на количестве файлов.

Пакеты шрифтов

Пакеты, содержащие шрифты должны наименоваться по формату [foundryname-]projectname[-fontfamilyname]-fonts с использованием символов нижнего регистра. Для подробного описания см. Packaging/FontsPolicy#Naming.

Пакеты дополнений (общие правила)

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

При наименовании собственное имя "дочернего" пакета предваряется именем "родительского" пакета так, чтобы итоговое имя пакета соответствовало формату %{parent}-%{child}.

Примеры:

gnome-applet-netmon (апплет netmon для gnome, связан с gnome)
php-adodb (поддержка функций adodb для php, связан с php)
python-twisted (модуль twisted для python, связан с python)
xmms-cdread (поддержка функций прямого чтения cd-дисков для xmms, связан с xmms)

Существует ряд исключений из вышеописанного правила наименования пакетов дополнений, которые будут приведены далее.

Пакеты дополнкений (httpd, pam и SDL)

Для пакетов, связанных с такими родительскими пакетами как Apache httpd, pam или SDL используется другая схема наименования. Имена дополнений для pam и SDL должны удовлетворять формату %{parent}_%{child}, где символ нижнего подчеркивания "_" используется в качестве разделителя. Имена дополнений для Apache httpd должны удовлетворять формату mod_%{child}, где символ нижнего подчеркивания "_" также используется в качестве разделителя. В большинстве случаев имена архивов, используемые источниками, изначально соответствуют приведенным схемам.

Примеры:

mod_perl (пакет с компонентами perl для Apache httpd, связан с httpd)
pam_krb5 (пакет с компонентами krb5 для pam, связан с pam)
SDL_gfx (пакет с дополнительными графическими компонентами для SDL, связан с SDL)
SDL_ttf (пакет поддержки отображения шрифтов TrueType для SDL, связан с SDL)

Пакеты дополнений (плагины Eclipse)

Имена пакетов, включающих плагины для Eclipse, ДОЛЖНЫ следовать формату eclipse-<projectname>. Например, пакет с плагином anyedit для Eclipse должен иметь имя eclipse-anyedit.

Пакеты дополнений (компоненты emacs)

Для пакетов, содержащих дополнительные компоненты для emacs (которые расширяют функциональность emacs-совместимых редакторов) применяется собственная схема наименования. Это связано с тем, что использование дной и той же компоненты различными emacs-совместимыми редакторами, такими как например, Emacs и XEmacs (а также, возможно, и разрабатываемыми версиями этих редакторов) является распространенной практикой. В общем случае имя пакета должно основываться на имени emacs-компоненты, которое было установлено источником.

Если компонента добавляет функциональность для более чем одного emacs-совместимого редактора, имя пакета должно иметь форму emacs-common-$NAME. При этом основной пакет должен содержать только файлы, являющиеся общими для всех emacs-совместимых редакторов, а код, специфичный для каждого конкретного редактора $EDITOR-$NAME, должен размещаться в соответствующих субпакетах, например, xemacs-$NAME, emacs-$NAME (последний пакет содержит код, специфичный для GNU Emacs). Пример использования приведенной - пакет emacs-common-muse.

Если же компонента предназначена для расширения функциональности одного emacs-совместимого редактора, то имя пакета должно иметь вид $EDITOR-$NAME. Примером использования данной схемы является пакет emacs-auctex, который собирается только для GNU Emacs.

Примеры:

emacs-common-muse (компонента muse для всех emacs-совместимых редакторов)
xemacs-muse (субпакет с компонентами muse, содержащий только файлы, относящиеся к XEmacs)
emacs-autex (компонента autex, используемая только для GNU Emacs)

Пакеты дополнений (модули erlang)

Пакеты, включающие модули erlang (и, следовательно, связанные с родительским пакетом erlang), используют собственную схему наименования. Имена таких пакетов должны основываться на исходных именах erlang-модулей, установленных источником. Формат имени erlang-$NAME. В случае возникновения сомнений в качестве имени следует использовать имя, указываемое в директиве импортирования, в какой-либо программе-сценарии, использующей рассматриваемый модуль.

Пример:

erlang-esdl (модуль erlang с именем esdl)

Пакеты дополнений (расширения gnome shell)

Имена пакетов, включающих расширения для gnome shell, должны начинаться с префикса gnome-shell-extension-. При этом указанный префикс должен быть в единственном числе (т.е. использование gnome-shell-extensions не допустимо).

Пакеты дополнений (модули OCaml)

Пакетам, включающим модули OCaml, а также библиотеки и синтаксические расширения должны назначаться имена вида ocaml-foo. Примеры: ocaml-extlib, ocaml-ssl.

Указанная схема не должна применяться к приложениям, написанным на OCaml, вместо этого пакеты, включающие такие приложения, должны иметь свои исходные имена. Примеры: mldonkey, virt-top, cduce.

Пакеты дополнений (расширения OpenOffice.org)

Пакеты, включающие расширения OpenOffice.org (и, следовательно, связанные с родительским пакетом OpenOffice.org), используют собственную схему наименования. Имена таких пакетов должны основываться на исходных именах расширений OpenOffice.org, установленных источником. Формат имени openoffice.org-$NAME.

Пакеты дополнений (модули perl)

Пакеты, включающие модули perl (и, следовательно, связанные с родительским пакетом perl), используют иную схему наименования. Имена таких пакетов должны иметь вид perl-CPANDIST, где CPANDIST - имя включаемого в пакет оригинального модуля CPAN (который в большинстве случаем является также элементарным (unit-) модулем perl). В тех редких случаях, когда возникает необходимость разделения исходного модуля CPAN для включения его содержимого в состав нескольких небольших субпакетов, например, из-за существующих зависимостей, имя каждого из субпакетов должно иметь вид perl-CPANDIST-Something.

Примеры:

perl-Archive-Zip (Archive-Zip - имя оригинального CPAN модуля)
perl-Cache-Cache (Cache-Cache - имя оригинального CPAN модуля)

Пакеты дополнений (модули php)

Для подробной информации по схеме наименования модулей PHP см. Packaging/PHP#NamingScheme .

Пакеты дополненй (модули python)

Пакеты, включающие модули python (и, следовательно, связанные с родительским пакетом python), используют собственную схему наименования. Имена таких пакетов должны основываться на исходных именах модулей python, установленных источником. Формат имени python-$NAME. В случае сомнений в качестве имени следует использовать имя, указываемое в директиве импортирования, в какой-либо программе-сценарии, использующей рассматриваемый модуль.

Примеры:

python-psycopg  (модуль python с именем psycopg)
python-simpletal (модуль python с именем simpletal)
python-tpg (модуль python с именем tpg)

Из приведенного правила существует одно исключение. Если в имени источника присутствует строка "py" (или "Py"), то в этом случае допускается использование такого имени в качестве имени пакета. Например, имя пакета pygtk является допустимым.

Если исходное имя модуля содержит символ точки, то в этом случае необходимо руководствоваться установленным правилом замены "." на "-".

Пакеты дополнений (модули python3)

Rpm-пакеты, имена которых содержат python в качестве префиксной или суффиксной части, являются rpm-пакетами дополнений python2, поэтому для имен пакетов дополнений python3 применяется другой префикс: python3. При этом действуют два дополнительных ограничения, которые не применяются к пакетам python2:

1. В силу необходимости идентификации принадлежности модуля к python3, исключение, относящееся к именам, содержащим "py", и применяемое для пакетов python2, не действует.
2. Поиск пакетов, содержащих модули, не должен требовать учета текущей используемой версии python.

Т.о. все пакеты с модулями python3 ДОЛЖНЫ содержать строку python3 в составе своего имени. В остальном имя пакета должно соответствовать тому же формату, что используется для пакетов с модулями python2. Несколько примеров:

Имя пакета Fedora для python 2	Исходное имя	Имя пакета Fedora для Python 3
python-lxml	lxml	python3-lxml
pygtk2	pygtk	python3-pygtk
gstreamer-python	gst-python	gstreamer-python3
gnome-python2	gnome-python	gnome-python3
rpm-python	(часть rpm)	rpm-python3

Пакеты дополнений (модули R)

Пакеты, включающие модули R (и, следовательно, связанные с родительским пакетом R), используют собственную схему наименования. Имена таких пакетов должны основываться на исходных именах модулей R, установленных источником. Формат имени R-$NAME. В случае сомнений в качестве имени следует использовать имя, указываемое в директиве импортирования, в какой-либо программе-сценарии, использующей рассматриваемый модуль R.

Примеры:

R-mAr (модуль R с именем mAr)
R-RScaLAPACK (модуль R с именем RScaLAPACK)
R-waveslim (модуль R с именем waveslim)

Пакеты дополнений (активные элементы Sugar)

Имена пакетов, содержащих активные элементы Sugar, должны иметь префикс sugar-. Для подробностей см. Packaging/SugarActivityGuidelines .

Пакеты дополнений (расширения Tcl/Tk)

Имена пакетов, содержащих расширения Tcl/Tk, должны содержать в качестве префикса строку tcl-. Данное правило распространяется на все пакеты Tcl/Tk, включая пакеты, изначально содержащие tcl в составе имени. Для подробностей см. Packaging/Tcl#NamingConventions.

Пакеты дополнений (локализации)

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

Примеры:

ttfonts-zh_TW (дополнение, включающее локализацию zh_TW для шрифтов из семейства ttfonts)
ttfonts-zh_CN (дополнение, включающее локализацию zh_CN для шрифтов из семейства ttfonts)

Пакеты дополнений (TeX)

Т.к. в Fedora в прошлом осуществлялась смена среды TeX, имена пакетов TeX не должны содержать привязки к конкретной реализации TeX (TeX Live или teTeX). Вместо этонго имена таких пакетов должны включать префикс "tex-".