Сборка пакетов/Соглашение по стилю RPM-пакетов/Стиль RPM-пакетов

Перейти к: навигация, поиск
Localize.png Эта статья содержит фрагменты на иностранном языке. Вы можете помочь переведя её до конца. (cм. руководство по переводу)
Стиль RPM-пакетов SUSE

Далее

Стиль RPM-пакетов

Этот раздел описывает стиль RPM-пакетов SUSE. Почти вся информация здесь собранная, отсортирована по разделам имена которых соответствуют секциям или тегам используемым в файлах спецификации(spec). Исключением является последний раздел, в котором описываются подпакеты (subpackages).


Вводный комментарий

Официальные файлы спецификации(spec) SUSE начинаются со следующего вводного комментария: 

 #
 # spec file for package PackageName (Version PackageVersion)
 #
 # Copyright 2008 SUSE LINUX Products GmbH, Nuernberg, Germany.
 #
 # All modifications and additions to the file contributed by third parties
 # remain the property of their copyright owners, unless otherwise agreed
 # upon. The license for this file, and modifications and additions to the
 # file, is the same license as for the pristine package itself (unless the
 # license for the pristine package is not an Open Source License, in which
 # case the license is the MIT License). An "Open Source License" is a
 # license that conforms to the Open Source Definition (Version 1.9)
 # published by the Open Source Initiative.

После строки "# Copyright 2008 SUSE Linux Products GmbH, Nuernberg, Germany." вы можете добавить "# Copyright Your Name <your@e-mail.address>".

Comments that start with "# Copyright" will be preserved during updates of the licensing header, which is performed during package submission.


norootforbuild

Строка начинающаяся с: 

# norootforbuild

означает что пакет может быть создан обычным пользователем, а не только root'ом(используется build скрипт). Это означает, что сборка пакета стала более безопасной, так как создание пакета без прав доступа супер пользователя(root'а), имеет гораздо меньше шансов сломать установленную систему.

Устарело для SuSE 9.2 и выше.


Тег BuildRequires

Этот тег определяет какие пакеты должны быть установлены для сборки данного пакета, он автоматически разрешает зависимости. До SL 10.1 этот тег автоматически генерировался тегом neededforbuild, если собирался в SUSE. Данный тег используется вместо neededforbuild начиная с SL 9.1.

См. также теги PreReq и Requires.

usedforbuild

Строка начинающаяся с: 

# usedforbuild

определяет все пакеты используемые для сборки данного пакета. Заменено тегом BuildRequires начиная с SUSE Linux 9.1.


Тег Name

Название пакета и архива исходных кодов должны быть одинаковыми, если это не противоречит следующим правилам:

  • Название пакета может содержать буквы, числа, тире и символ нижней черты (a-z, A-Z, 0-9, -, _).
  • Правила наименования для специальных пакетов:

Тип пакета

Имя пакета

XXX - означает:

Perl module

perl-XXX

оригинальное имя модуля

Python module

python-XXX

оригинальное имя модуля


Тег License

Этот тег определяет список названий лицензий(через точку с запятой ";") для пакета. Он проверяется при включении пакета в репозитории openSUSE Factory и должен быть правильно сформирован. Если лицензия не имеет хорошо известного имени, свяжитесь с legal-devel@suse.de, не используйте классификацию начинающуюся с 'Any ...', исключение может быть сделано только в том случае, если вы точно знаете что делаете. Используйте "Any permissive" если нет никаких видимых обязательств.

Если данная лицензия существует в нескольких версиях, вы должны указать и версию лицензии. Версия добавляется к краткому имени лицензии: если это аббревиатура написанная прописными буквами - после маленькой буквы "v" (как это описано в руководстве по сборке пакетов в дистрибутиве fedore), иначе - используется символ пробела и заглавная V (" V"). Бесполезные записи вроде: "Other License(s), see package" или "Contact Author", все еще могут быть найдены в некоторых пакетах, пожалуйста помогите исправить их. Такие пакеты не могут быть приняты в дистрибутив Factory. В случае сомнений, обращайтесь к legal-devel@suse.de .

Примеры: 

License:      GPLv3
License:      GPLv2+; Apache V2.0
License:      LGPLv2.1+
License:      LGPLv2.1; OSI_COMPLIANT_FREE(no modification)
License:      LGPLv3; GFDLv2.1;
License:      OSI_COMPLIANT_FREE(Public domain)


Тег Group

Этот тег определяет к какой группе принадлежит пакет.

Полный список допустимых групп RPM, и их описание можно найти в разделе Группы RPM.


Тег Version

Версия пакета и архива исходных кодов должны быть одинаковыми, если это не создает проблем для обновления пакета:

Утилита RPM использует версию пакета для того, чтобы определить какой пакет новее, и при обновлении пакет с меньшей версией заменяет на пакет с большей версией. RPM разбивает версию пакета(с помощью разделительных точек) на старший(major) номер версии, младший номер версии, и т.д., и сравнивает соответствующие номера(по алфавиту). Если пользователь хочет установить более старую версию пакета, он должен использовать опцию --oldpackage.

Данная таблица показывает корректную последовательность версий:


С версии

К версии

1.0

1.1

1.0

1.0.1

1.0

1.0p1


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

С версии

К (неверно)

К (верно)

1.0b1

1.0

1.0.0 или 1.0p0

1.0rc1

1.0

1.0.0

1.0rc1

1.0p2

1.0.2

Это правило по которому упорядочиваются номера версий, т.е. 1.0 < 1.0b1 < 1.0p0 < 1.0rc1 < 1.0.0. Поэтому нежелательно в качестве версии использовать 1.0.0, лучше использовать меньшую версию, что-то вроде 0.99rc1, или(к примеру) в случае последовательности 0.45, 0.46-rc1, 0.46, то версию 0.46-rc1 лучше заменить на 0.45.99-rc1.


Тег Release

Номер релиза обнуляется при каждом обновлении версии, и увеличивается на единицу при любом изменении в пакете.

A mechanism has been added to differentiate packages that are distinct from the common code base. It may happen if multiple products are based on the same code base and a package needs a special adjustment for a product. The solution is that the release number is versioned. For example, the latest common build of a package has release number 14 and the package sources are modified for a particular product. Then the package for the product has the release numbers 14.0, 14.1, 14.2, etc., and the same package in the common base continues with the usual release numbers 15, 16, 17, etc.

In the past, the value was increased by one each time the package was rebuilt. The idea was to differentiate two builds of the same package in case the packages used for build were modified. It brought more problems than advantages, so the release number is increased only when the package itself changes now.


Тег Autoreqprov

Тег используется для автоматического обнаружения и обеспечения зависимостей.

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

К примеру, это может быть пакет содержащий плагин(plug-in) с большим числом зависимостей, но не загружаемый по умолчанию, и используемый только некоторыми пользователями. В этом случае может быть разумно отключить этот тег, дабы избежать большого числа зависимостей, но не забудьте упоминуть об этой проблеме в файле README. Однако, даже в этом случает существует более корректное решение проблемы, при котором автоматическое обнаружение зависимостей может быть включено: Проблемный плагин можно вынести в отдельный/дополнительный пакет, который будет содержать множество зависимостей.


Тег PreReq

Этот тег определяет, какие зависимости должны быть удовлетворены для корректной установки пакета. Данное поле должно содержать все пакеты или абсолютное имя утилиты(с полными путями), которые используются в секциях %pre, %post и %triggerin.

Абсолютное имя используется для базовых утилит, например /bin/touch или /bin/rm. Оно используется, потому что такие пути - стандарт для всех *nix'ов. А также, устойчиво к разным переименованиям и разделениям(слияниям) пакетов. Для менее распространенных утилит, должно быть использовано название пакета. Скорее всего, это изменится в будущем.

Данный пример взят из пакета deb: 

PreReq:       /bin/touch
[...]
%post
cd /var/lib/dpkg
for f in diversions statoverride status ; do
        if [ ! -f "$f" ] ; then
                touch "$f"
        fi
done

Пример взят из пакета cups-drivers: 

PreReq:       sysvinit, sh-utils
 [...]
 %post
 test -x /etc/init.d/cups && \
         /etc/init.d/cups status >/dev/null && \
         /etc/init.d/cups reload >/dev/null
 # exit 0 needed here to ignore test return code
 exit 0

SUSE предоставляет макросы, которые можно использовать в теге PreReq. Они предоставляют требуемые зависимости для соответствующих макросов, используемых в секции %post. См. примеры в %install_info.

Вы также можете использовать теги Requires(pre), Requires(post), Requires(preun) и Requires(postun), чтобы конкретизировать какая секция от чего зависит, но это не обязательно.

См. также теги Requires и BuildRequires.


Тег Requires

Этот тег определяет какие пакеты должны быть установлены для корректной работы данного пакета. Это поле должно содержать только те пакеты, которые необходимы для работы данного пакета, но при этом не определяются автоматически(тегом Autoreqprov).

Желательно указывать только имена требуемых пакетов. Однако, если интерфейс взаимодействия пакетов(подпакетов) меняется(в какой-либо версии), то пакет может потребовать и определенную версию, но не номер релиза. Это обычно для *-devel пакетов(пакетов с исходным кодом), к примеру, glibc-devel-<version> требует glibc-<version>. Точное соответствие версий, включая номера релизов, требуется только в очень исключительных случаях.

См. также теги PreReq и BuildRequires.


Тег Recommends

Этот тег определяет какие пакеты рекомендуется использовать с данным пакетом, например: дополнительные плагины которые рекомендуется использовать с данным пакетом, фронтенд для консольного приложения и т.д.

Тег Summary

Этот тег должен содержать краткое(в одну строку) описание пакета, его максимальная длинна - 80 символов. Он должен бить заполнен во всех стандартных пакетах, и не должен содержать контексто- зависимых фактов, т.е. он должен быть самодостаточным. (Используется например в rpm -qa --queryformat  %-80{SUMMARY})

Он должен описывать главную основную функцию и особые свойства пакета, чтобы помочь пользователю сравнить несколько похожих пакетов. К примеру, словосочетание "Web Browser" подходит подходит к любому браузеру, но используя дополнительные слова (такие как: minimalistic, complex, GNOME, KDE, text-based, fast, or author's), вы можете дать краткую характеристику для своего пакета.

The RPM spec file contains only the English version to keep the RPM database small. The localizations are managed by YaST.


Рекомендации по стилю


  • Use title-style capitalization. This means most words are capitalized except prepositions and articles.
  • Do not use an article at the beginning of the line.
  • Do not enter a period at the end of the line.
  • Try to avoid complete sentences. For example, use “Meta Package with SUSE Contributors as Authors” instead of “This is a meta package. It contains SUSE contributors as authors.”


Примеры: 

Summary:    High Quality Asteroids Clone
Summary:    Enhanced Interactive Python Shell
Summary:    Tool to Verify 3D Configuration
Summary:    Graphics Library for Framebuffer Devices
Summary:    Converter for Several 3-Dimensional Object File Formats


Тег Source

Архив(tarball) с исходниками проекта должен быть сжат утилитой bzip2. Не бойтесь переупаковать архив, если это конечно не запрещено лицензией. В случае нескольких файлов с исходниками, каждый из них должен быть сжат, если его размер превышает 100kB. Везде где это возможно, пользуйтесь макросами %name и %version.

Начиная с openSUSE 11.0 можно использовать архивы сжатые по алгоритму LZMA, для предыдущих версий дистрибутива - требуется указать "BuildRequires: lzma" (этого достаточно для распаковки архивов макросом %setup).

Примеры: 

Source:    %name-%version.tar.bz2
Source:    bugz-tarball-(3.0.0).tar.bz2

Elements in the source tag must be a relative URI to the content in the RPM from the dir level of the spec file. However, you can also use SourceN tags for documentation purposes. Example: 

Source0:   http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-3.2rc1.tar.gz


Тег Patch

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

  • Имя автора.
  • Детальное описание исправленной проблемы.
  • URL-адрес откуда был взят патч(если он существует).

Название патч-файла должно содержать:

  • Имя и версию архива исходного кода из которого получен патч файл
  • Несколько слов о том для чего нужен данный патч
  • Иметь расширение .patch

Патчи должны быть в унифицированном формате (diff -u) и должны быть созданы/применены в директории с исходным кодом (%patch -p0). Исключение может быть сделано только для патчей полученных из других источников. В этом случае должны быть сохранены: оригинальное имя, суффикс и формат патча.

Каждый патч-файл размером больше 100kB должен быть сжат (в формате bzip2). Везде, где это возможно, должны быть использованы макросы %name и %version.

Примеры: 

Source:   %{name}-%{version}.tar.bz2
Patch0:   %{name}-%{version}-autoconf.patch
Patch1:   %{name}-%{version}-gcc31.patch

Чтобы применить патч, макрос %patch должен быть использован после макроса %setup: 

%setup -q
%patch0
%patch1

Подробнее о см. патчи.


Тег BuildRoot

Этот тег должен использоваться всегда. Обычно он ссылается на %{_tmppath}/%{name}-%{version}-build.


Тег Description

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

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

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

The RPM spec file contains only the English version to keep the RPM database small. The localizations are managed by YaST.


Рекомендации по стилю

  • When referring to the user, use the pronoun "you."
  • Avoid contractions, such as "can't" and "isn't."
  • Clarity is crucial. Use shorter sentences and simplify the structure to maintain a clear, professional style. Instead of using semicolons, split the sentence in two. If sentences are long or awkward, try rephrasing.
  • Avoid use of emotions and "please."
  • If-Then is not a grammatical structure. Phrases beginning with if need not be followed by phrases beginning with then.
  • Do not capitalize after a colon unless the phrase preceding the colon refers to multiple sentences.
  • Avoid use of "etc." It tends to break up the sentence flow. If it is used, it should be followed by a comma except at the end of the sentence. When giving examples, it is not necessary to use "etc." or a replacing structure, because the reader does not expect an example to include all possible items.
  • Semicolons (;) are mainly used to join two independent but related sentences. They can also be used in places of commas in a complicated series. It is preferable to avoid them when possible and instead break the text into smaller pieces.
  • Avoid "e.g." and "i.e." where possible. Many people do not understand the correct meanings of these abbreviations, so it is best to avoid them. Replace with phrases like "for example" or "such as". If you need to use them, use commas around "e.g.," "i.e.," and "for example" (unless they begin or end the statement. In these cases, use a comma only after or before). For example, this is an example.
  • The symbols "/" and "\" are not, under any circumstances, to be used as punctuation.
  • Use "so-called" only when the term to which it refers is a nickname or misnomer, not in reference to the correct term. Do not replace with "what is known as" or similar constructions.
  • Word List: address book, applet, back-end, Bash (according to GNU Bash manual), boot loader, check box, check mark, command line, deactivate, deselect (verb), dialog, dial-up (not dial-in), double-click, e-mail, filename, file system, formulas, framebuffer, front-end, The GIMP (current project standard), GNOME (current project standard), graphical user interface, graphics card, hard disk.
  • Jokes do not travel. Do not use jokes or funny statements, because they are usually only recognized in certain locations and probably confuse others who are not familiar with these local usages.
  • "commandline command" is repetitive. "command" is usually a command line–specific term.


Подпакеты

Подпакеты(subpackage, иногда переводят как субпакеты) используются по следующим причинам:

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

Обычно имя подпакета содержит:

  • Имя основного пакета.
  • Несколько слов характеризующих содержание пакета.

В качестве разделителя (между именем пакета и подпакета), по умолчанию используется символ тире '-'.

Примеры: 

apache.rpm
apache-contrib.rpm
apache-devel.rpm
apache-doc.rpm
apache-example-pages.rpm
apache-testsuite.rpm

По крайней мере следующие теги должны быть опрделены для каждого пакета (в разделе %package имя_подпакета):

  • Group
  • Summary
  • а также раздел Description (%description имя_подпакета )

Для подпакетов можно добавить собственные разделы в виде: %название_раздела имя_подпакета

Пример создания подпакета gw6c-docs, отрывок .spec файла пакета gw6c: 

%package docs
Summary:    Documentation for gw6c
Group:      Documentation  
Requires:   %{name} = %{version}-%{release}  

%description docs  
This is package with addition *.pdf documentation for gw6c package.

%files docs  
%defattr(-,root,root,-)  
%doc *.pdf

Более подробную информацию об использовании подпакетов см. в статье Создание субпакетов


Теги Provides и Obsoletes

Эти теги используется при переименовании, разделении или объединении пакетов. Детально это описано в Package Dependencies и статье Зависимости пакета.

Далее

В начало

2. Группы RPM
Источник — «https://ru.opensuse.org/index.php?title=Сборка_пакетов/Соглашение_по_стилю_RPM-пакетов/Стиль_RPM-пакетов&oldid=21221»