Политика оформления библиотек — различия между версиями

Материал из Rosalab Wiki
Перейти к: навигация, поиск
(Копия ревизии 14984 статьи Libraries policy)
 
(Первая попытка перевода статьи.)
Строка 1: Строка 1:
 
[[Категория:Packaging Policies]]
 
[[Категория:Packaging Policies]]
−
{{Введение|In order to enjoy better upgrades, it is important to keep old major library versions in the system so that programs which use them still work.}}
+
{{Введение|Чтобы создать лучшее обновление, важно сохранить старые major версии библиотеки в системе, чтобы программы, которые их используют, продолжили работать.}}
  
−
== Naming Conventions ==
+
== Правила составления имён ==
−
Libraries in {{file|/usr/lib}} and {{file|/lib}} '''must be separately packaged''', in a library-only package, named with the name of the main library concatenated with the major of the library (or soname, see below). These packages <b>should not contain any binaries</b>, which should be in a different package. The packages can contain other files (e.g., documentation or license) provided that these files are installed to location specific to the package (e.g, {{pkg|libfoo2}} may install something to {{file|/usr/share/doc/libfoo2/}}). The goal is to be able to install {{pkg|libfoo1}} and {{pkg|libfoo2}} on the same system.
+
Библиотеки в {{file|/usr/lib}} и в {{file|/lib}} '''должны быть упакованы отдельно''' в специальный библиотечный пакет с именем, содержащим название основной библиотеки и major (или soname, см. далее). Эти пакеты <b>не должны содержать никаких бинарных файлов</b>, которые должны быть в другом пакете. Пакеты могут содержать другие файлы (например, документацию или лицензию) при условии, что эти файлы установлены по адресу, специфичному для пакета (например, {{pkg|libfoo2}} может установить что-то в {{file|/usr/share/doc/libfoo2/}}). Цель состоит в том, чтобы установить {{pkg|libfoo1}} и {{pkg|libfoo2}} в одну систему.
  
−
First of all, it is fundamental that the source rpms keep the same name without any major number, so that the git repository contains only one branch for each package.
+
Прежде всего фундаментально, что исходные rpm сохраняют одно имя без какого-либо major номера, так что git репозиторий содержит только одну ветку каждого пакета.
  
−
When the distribution must have two versions of the same library at the same time (for example, qt1 and qt2), the sources rpms will be separated so that we can include both versions in the distribution as two different, independently maintained packages.
+
Когда дистрибутив должен иметь две версии одной библиотеки одновременно (например, qt1 и qt2), то исходные rpm будут разделены, чтобы мы могли включить обе версии в дистрибутив в виде двух разных, независимо поддерживаемых пакетов.
  
−
Here's a generic example: the following happens when the library comes with binaries, config files, or anything else that won't fit in the main library package (where only libraries go) nor in the devel package (where headers and devel libraries go (e.g. <i>.so</i> and <i>.a</i>)).
+
Вот общий пример: следующее происходит, когда библиотека идёт с бинарными или конфигурационными файлами или какими-либо ещё, которые не вписываются ни в основной пакет библиотеки (где должны быть только библиотеки), ни в devel пакет (где должны быть заголовочные и devel библиотеки, такие как <i>.so</i> и <i>.a</i>)).
  
−
* Source package:
+
* Исходный пакет:
 
** foo-2.3.4-4-rosa2012.src.rpm
 
** foo-2.3.4-4-rosa2012.src.rpm
  
−
* Binary packages:
+
* Бинарные пакеты:
 
** foo-2.3.4-4-rosa2012.arch.rpm  
 
** foo-2.3.4-4-rosa2012.arch.rpm  
 
** libfoo2-2.3.4-4-rosa2012.arch.rpm
 
** libfoo2-2.3.4-4-rosa2012.arch.rpm
 
** libfoo-devel-2.3.4-4-rosa2012.arch.rpm
 
** libfoo-devel-2.3.4-4-rosa2012.arch.rpm
  
−
If foo-2.3.4-4-rosa2012.src.rpm produces several libraries, then these libraries must be packaged in separate files - libfoo2-2.3.4-4-rosa2012.arch.rpm, libbar2-2.3.4-4-rosa2012.arch.rpm, etc. However, devel files for them can be provided in a single package. Name of such single package may not start with 'lib'; however, it is desired for 32-bit and 64-bit packages to have different names (e.g., foo-devel and foo64-devel).
+
Если foo-2.3.4-4-rosa2012.src.rpm создаёт несколько библиотек, то эти библиотеки должны быть упакованы в отдельные файлы:  libfoo2-2.3.4-4-rosa2012.arch.rpm, libbar2-2.3.4-4-rosa2012.arch.rpm и т.д. Однако devel файлы могут быть собраны в один пакет. Имя такого пакета может начинаться с lib, однако для 32-битных и 64-битных пакетов желательно иметь разные имена (например, foo-devel и foo64-devel).
−
'''Rationale:''' -devel packages are not installed on standard end-user installations, so splitting them doesn't affect end-users but would make developers' life more difficult. Distinct names for 32-bit and 64-bit -devel packages allow to install packages for both architectures in the same system.
+
'''Обоснование:''' -devel пакеты не устанавливаются пользователем, поэтому разделение таких пакетов не влияет на пользователя, но может усложнить жизнь разработчику. Отдельные имена для 32-битных и 64-битных -devel пакетов позволяют устанавливать пакеты обеих архитектур в одной системе.
  
−
If upstream name itself starts with 'lib' (e.g., {{pkg|libxml2}}) then package with binaries can be named as {{pkg|libfoo-utils}} or {{pkg|libfoo-tools}} or something similar allowing to distinguish it from the library package.
+
Если апстримное имя само по себе начинается с lib (например, {{pkg|libxml2}}), то пакет с бинарными файлами можно назвать {{pkg|libfoo-utils}} или {{pkg|libfoo-tools}} или как-то похоже, чтобы можно было отличить его от пакета библиотеки.
  
−
==== Naming on x86_64 ====
+
==== Названия для x86_64 ====
−
* Binary packages:
+
* Бинарные пакеты:
 
** foo-2.3.4-4-rosa2012.x86_64.rpm  
 
** foo-2.3.4-4-rosa2012.x86_64.rpm  
 
** lib64foo2-2.3.4-4-rosa2012.x86_64.rpm
 
** lib64foo2-2.3.4-4-rosa2012.x86_64.rpm
 
** lib64foo-devel-2.3.4-4-rosa2012.x86_64.rpm
 
** lib64foo-devel-2.3.4-4-rosa2012.x86_64.rpm
  
−
To handle this complexity, use {{macro|%mklibname}}:
+
Чтобы было проще, используйте {{macro|%mklibname}}:
  
 
==== %mklibname ====
 
==== %mklibname ====
−
The %mklibname macro is used to generate the library package names:
+
Макрос %mklibname используется для создания имён библиотечных пакетов:
 
* %mklibname [-d [-s]] name [[api] major]
 
* %mklibname [-d [-s]] name [[api] major]
−
** -d - generate a name for a devel package
+
** -d - создание имени для devel пакета
−
** -s - generate a name for a static package (to be used together with -d)
+
** -s - создание имени для static пакета (использовать вместе с -d)
−
** name - the library name (note that if the library name is libfoo, you should enter "foo", not "libfoo")
+
** name - имя библиотеки (обратите внимание, что если именем библиотеки является libfoo, то надо вводить foo, а не libfoo)
−
** major - the major number to be appended into the name (this should not be used with -d, except in packages mentioned in special cases below)
+
** major - основное число, которое должно быть добавлено в имя (не использовать вместе с -d, кроме особых случаев, упомянутых отдельно ниже)
−
** api - if the library has a SONAME like libfoo-1.2.so.4, api should be set to 1.2 and major to 4. This results in libfoo1.2_4
+
** api - если библиотека имеет, например, SONAME libfoo-1.2.so.4, то api будет 1.2, а major - 4. Результатом будет libfoo1.2_4
  
−
Example usage:
+
Примеры использования:
 
* %mklibname foo 5 => libfoo5
 
* %mklibname foo 5 => libfoo5
 
* %mklibname -d foo => libfoo-devel
 
* %mklibname -d foo => libfoo-devel
 
* %mklibname -d -s foo => libfoo-static-devel
 
* %mklibname -d -s foo => libfoo-static-devel
  
−
=== *.la files ===
+
=== Файлы *.la ===
−
Modern libtool works fine without *la files, so these files are dropped by default by spec-helper during the build process. Several exceptions are known at the moment that are hardcoded in the spec-helper code. If you think you have found one more exception, feel free to contact rpmbuild maintainers.
+
Современные libtool отлично работают без *.la файлов, поэтому эти файлы по-умолчанию отбрасываются spec-helper во время сборки. В настоящее время известно несколько исключений, которые включены в код spec-helper. Если вы считаете, что нашли ещё одно исключение, свободно обращайтесь к мейнтейнерам rpmbuild.
  
−
=== Special cases ===
+
=== Особые случаи ===
−
We described the default policy for library packages, however some special cases can happen and must be handled using the brain:
+
Мы описали основную политику для пакетов библиотек, однако, могут произойти некоторые особые случаи, которые должны быть рассмотрены вдумчиво:
  
−
* Remember to always check the <i>soname</i> of the libraries ({{cmd|objdump -x libfoo.so.1 <nowiki>|</nowiki> grep SONAME}}), because some sonames include the library version number, for example {{file|libfoo-1.2.so.4}}. In this case, the package should be named {{pkg|libfoo1.2_4-1.2.4-rosa2012}}.
+
* Не забывайте всегда проверять <i>soname</i> библиотек ({{cmd|objdump -x libfoo.so.1 <nowiki>|</nowiki> grep SONAME}}), потому что некоторые soname содержат номер версии библиотеки. Например, {{file|libfoo-1.2.so.4}}. В этом случае пакет должен быть назван {{pkg|libfoo1.2_4-1.2.4-rosa2012}}.
−
* Packages ending with a number should be handled by putting a "_" before the major, for example {{pkg|libfoo23_4-1.2-rosa2012}} (in this case the soname would be {{file|libfoo23.so.4}}).
+
* Пакеты, оканчивающиеся номером, должны быть снабжены "_" перед major. Например, {{pkg|libfoo23_4-1.2-rosa2012}} (в этом случае soname будет {{file|libfoo23.so.4}}).
−
* It is not necessary to split each library in separate packages: if a package contains several libraries, the name would be built from the main library of the package. If there are problems keeping libraries in the same package (e.g. their major may differ), the package should be split.
+
* Нет необходимости помещать каждую библиотеку в отдельный пакет: если пакет содержит несколько библиотек, имя можно взять из основной библиотеки пакета. Если есть проблемы с хранением библиотек в одном пакете (например, их major может отличаться), пакет должен быть разделён.
−
** When splitting libraries which were previously in a single package, you may need to add Obsoletes/Conflicts "across" the new packages, to hint Urpmi into putting them in the same transaction (ref: [http://archives.mandrivalinux.org/cooker/2009-06/msg00025.php libiptc and libiptables splitting])
+
** При разбиении библиотек, которые ранее были в одном пакете, вам может потребоваться добавить Obsoletes/Conflicts в новые пакеты, чтобы попросить Urpmi поместить их в одну транзакцию.
−
* If multiple versions of the package are maintained within the distro with different majors, or an expected future release is going to be source-incompatible in a major way (rebuild of concerned pkgs not being enough, and changes required are too big) with the current version (e.g. QT3/QT4/QT5), the devel package name should include the major. In the former case, the devel subpackage of the newest version should generally not contain the major, only the older versions.
+
* Если в дистрибутиве поддерживаются несколько версий пакета с разными major, или будущий релиз получится несовместимым по major (перестройка соответствующих pkgs не является достаточной, а требуемые изменения слишком велики) с текущей версией (например, QT3/QT4/QT5), то имя devel пакета должно содержать major. В предыдущем же случае devel субпакет новой версии обычно не содержит major, а только старые версии.
−
* Some applications (e.g., [[KDE 4 packaging policies#Library_policy|KDE ones]]) contain dynamic loading modules which are not libraries. Usually these modules are put into the main application subpackage. But sometimes it is better to include the modules in the library package if they are generally required to be installed when using the library (so that every application using the library doesn't have add manual requires on the modules). In general, decisions should be made on on a case-by-case basis. However, if modules are included in the library package, they '''must''' be in a versioned directory (e.g. {{file|/usr/lib/foo-2/module.so}} for a {{pkg|libfoo2}} package) so that installation of multiple versions of the library doesn't break.
+
* Некоторые приложения (например, [[KDE 4 packaging policies#Library_policy|KDE ones]]) содержат динамически загружаемые модули, которые не являются библиотеками. Обычно эти модули помещают в основной субпакет приложения. Но иногда лучше включать такие модули в библиотечный пакет, если их установка обычно требуется при использовании библиотеки (чтобы каждое приложение, использующее библиотеку, не требовало добавить руководство по модулям). В целом, решения должны приниматься индивидуально. Однако, если модули включены в библиотечный пакет, они '''должны''' попасть в каталог с версией (например, {{file|/usr/lib/foo-2/module.so}} для пакета {{pkg|libfoo2}}) , чтобы установка нескольких версий библиотеки была возможной.
  
−
=== Updating a package which is following the old library policy ===
+
=== Обновление пакета, который следовал старой политике оформления библиотек ===
−
Change the name of devel packages from {{macro|%libname-devel}} to "{{macro|%mklibname %name -d}}" (without {{macro|%major}}! though usually with {{macro|%api}} if present) as seen above and add an {{macro|Obsoletes}} for the previous name ("{{macro|%mklibname %name 2 -d}}" or "{{macro|%{_lib}%{name}2-devel}}", 2 being the major of the obsoleted devel package).
+
Измените имя devel пакета с {{macro|%libname-devel}} на {{macro|%mklibname %name -d}} (без {{macro|%major}}, хотя обычно с {{macro|%api}}, если есть), как показано выше, и добавьте {{macro|Obsoletes}} для предыдущего имени ({{macro|%mklibname %name 2 -d}} или {{macro|%{_lib}%{name}2-devel}}, где 2 - major устаревшего devel пакета).
−
Static-devel packages have to be switched to use {{macro|%mklibname %name -d -s}}. If in doubt, do not hesitate to ask in ROSA mailing lists.
+
Для static-devel пакетов надо произвести замену на {{macro|%mklibname %name -d -s}}. Если есть сомнения, свободно спрашивайте в списках рассылки ROSA.
  
−
== Provides and conflicts ==
+
== Provides и conflicts ==
−
At least {{macro|%name-devel <nowiki>=</nowiki> %version-%release}} should be provided by the -devel package. If the original tarball name differs from %name, you should also provide {{macro|tarballname-devel <nowiki>=</nowiki> %version-%release}}, for compatibility with other RPM-based systems. If multiple versions of the library are maintained within the distro, only the latest shall provide %name-devel. The older versions provided should provide {{macro|%name%major-devel}} or {{macro|%name%api-devel}} where applicable. The maintainer may also opt to provide {{macro|%name%major-devel}} or {{macro|%name%api-devel}} in the newest package as well, if the next major number raise is excepted to break source-compatibility (see the Special cases above).
+
Пакет -devel должен как минимум содержать {{macro|%name-devel <nowiki>=</nowiki> %version-%release}}. Если исходное имя тарбола отличается от %name, то вы также должны добавить {{macro|tarballname-devel <nowiki>=</nowiki> %version-%release}}, для совместимости с другими rpm-системами. Если в дистрибутиве содержится несколько версий библиотеки, только последняя должна называться %name-devel. Предыдущие версии должны иметь в названии, например, {{macro|%name%major-devel}} или {{macro|%name%api-devel}}. Но мейнтейнер также может выбрать {{macro|%name%major-devel}} или {{macro|%name%api-devel}} и для нового пакета, если следующий major по исходному коду окажется несовместимым (см. Особые случаи выше).
  
−
It's important to understand that putting a {{macro|Provides}} without the version information makes it impossible for later client RPM's to put a version information on dependencies, e.g. "{{macro|Provides: foo-devel}}" is NOT enough, please use "{{macro|Provides: foo-devel <nowiki>=</nowiki> 1.2.4-3-rosa2012}}".
+
Важно понимать, что включение {{macro|Provides}} без информации о версии делает невозможным последующее включение информации о версии. Например, "{{macro|Provides: foo-devel}}" - НЕ годится. Пожалуйста, используйте "{{macro|Provides: foo-devel <nowiki>=</nowiki> 1.2.4-3-rosa2012}}".
  
−
If multiple versions of the library are maintained within the distro and the exception allowing the use of major in lib -devel package name is used, you have to add {{macro|conflicts}} with the other devel package if they are not parallel installable. (this is often the case when the major changed, without renaming the headers).
+
Если в дистрибутиве содержится несколько версий библиотеки, и использовано исключение в виде добавления major в название lib -devel пакета, вам нужно добавить {{macro|conflicts}} с другими devel пакетами, если их нельзя устанавливать параллельно. Это часто бывает, когда major изменился без переименования заголовочных файлов.
  
  
−
== Adding an old-majored version into the distro ==
+
== Добавление старой версии в дистрибутив ==
−
If a package is upgraded to have a new major, and it will be noticed that it is not source-compatible with the previous release and the users of the library cannot be straight-forwardly patched to use the new API, the older library should be maintained in parallel with the new one. The creation process follows with the example package "foo", just upgraded to major 3:
+
Если пакет обновлён до нового major, и будет замечено, что он не совместим с исходным кодом предыдущего релиза, и пользователи библиотеки не смогут быть прямо пропатчены для использования нового API, то старая библиотека должна поддерживаться параллельно с новой. Процесс создания на примере пакета foo, который обновляется до major 3:
−
# Git copy package "foo" from just before the major 3 update to package "foo2". Also change the {{macro|Name}} to "foo2" and rename the spec file to {{file|foo2.spec}}.
+
# Копируется git foo непосредственно перед обновлением foo2 до major 3. Также изменяется  {{macro|Name}} на foo2 и имя спек-файла на {{file|foo2.spec}}.
−
# Add 2 (the major) to the devel package name, i.e. libfoo2-devel instead of libfoo-devel. This can be achieved by adding the parameter {{macro|%major}} into the {{macro|%mklibname}} call of {{macro|%devname}}.
+
# Добавляется 2 (major) к имени devel пакета, например, libfoo2-devel вместо libfoo-devel. Это можно осуществить добавлением параметра {{macro|%major}} в {{macro|%mklibname}} для {{macro|%devname}}.
−
# Modify any provides so that they have the major number in them. E.g. {{macro|%name-devel}} or {{macro|foo%major-devel}} is fine.
+
# Редактируются все provides, чтобы в них был major. Например, {{macro|%name-devel}} или {{macro|foo%major-devel}}.
−
# Add Conflicts: {{macro|foo-devel}} if the package conflicts with the newer devel package.
+
# Добавляется Conflicts: {{macro|foo-devel}}, если пакет конфликтует с новым devel пакетом.
  
−
No changes are needed in the .spec of the newer version.
+
Внесения каких-либо изменений в .spec для новой версии не требуется.
  
−
== An example ==
+
== Пример ==
−
Here's an example of a specfile for a package with no binary and config files, so only library binary packages are needed. (Note that the spec file is not valid, it is only an example that shows how it works and to highlight the difference with a normal package.
+
Вот пример спек-файла для рассматриваемого библиотечного пакета без бинарных и конфигурационных файлов. Обратите внимание, что спек-файл нерабочий. Это только пример для демонстрации разницы с обычным пакетом.
  
 
<pre>
 
<pre>
−
# api is the part of the library name before the .so
+
# api - это часть имени библиотеки перед .so
 
%define api 1.2
 
%define api 1.2
−
# major is the part of the library name after the .so
+
# major - это часть имени библиотеки после .so
 
%define major 1
 
%define major 1
 
%define libname %mklibname %{name} %{api} %{major}
 
%define libname %mklibname %{name} %{api} %{major}
 
%define devname %mklibname %{name} -d
 
%define devname %mklibname %{name} -d
  
−
#(!) summary for SRPM only
+
#(!) summary только для SRPM
 
Summary:        C++ interface for popular GUI library gtk+
 
Summary:        C++ interface for popular GUI library gtk+
 
Name:          gtkmm
 
Name:          gtkmm
Строка 98: Строка 98:
  
 
%description
 
%description
−
#Full and generic description of the whole package. (this will be the SRPM
+
#Полное и общее описание всего пакета. (Это будет только
−
#description only)
+
#для SRPM)
  
 
#----------------------------------------------------------------------------
 
#----------------------------------------------------------------------------
  
−
#main package (contains .so.[major]. only)
+
#Главный пакет (содержит только .so.[major].)
 
%package -n %{libname}
 
%package -n %{libname}
−
#(!) summary for main lib RPM only
+
#(!) summary только для главной lib RPM
 
Summary:        Main library for gtkmm  
 
Summary:        Main library for gtkmm  
 
Group:          System/Libraries
 
Group:          System/Libraries
Строка 115: Строка 115:
 
%files -n %{libname}
 
%files -n %{libname}
 
# ..
 
# ..
−
# include the major number (and api if present) in the file list to catch
+
# содержит major (и api, если есть) в списке файлов, чтобы захватить
−
changes on version upgrade
+
изменения при обновлении версии
 
%{_libdir}/lib-%{api}.so.%{major}*
 
%{_libdir}/lib-%{api}.so.%{major}*
  
Строка 125: Строка 125:
 
Group:          Development/GNOME and GTK+
 
Group:          Development/GNOME and GTK+
 
Requires:      %{libname} = %{EVRD}
 
Requires:      %{libname} = %{EVRD}
−
#(!) Not mandatory, since we prefer to use pkgconfig-style dependencies.
+
#(!) Не обязательно, так как мы предпочитаем использовать зависимости типа pkgconfig.
−
# But if the library doesn't have pkgconfig files, this provide is a must
+
# Но если в библиотеке нет файлов pkgconfig, это необходимо
 
Provides:      %{name}-devel = %{EVRD}
 
Provides:      %{name}-devel = %{EVRD}
  
Строка 144: Строка 144:
 
</pre>
 
</pre>
  
−
== See Also ==
+
== См. также ==
 
[[KDE_SC_4_packaging_policies#Library_policy|Policy for KDE 4 Libraries]]
 
[[KDE_SC_4_packaging_policies#Library_policy|Policy for KDE 4 Libraries]]
  
 
<hr>
 
<hr>
  
−
{{Примечание|This Policy is based on the [http://wiki.mandriva.com/en/Development/Tasks/Packaging/Policies/Libraries Mandriva Libraries Policy].}}
+
{{Примечание|Эта Политика основана на Политике Оформления Библиотек Mandriva.}}

Версия 22:03, 29 августа 2018

Чтобы создать лучшее обновление, важно сохранить старые major версии библиотеки в системе, чтобы программы, которые их используют, продолжили работать.

Правила составления имён

Библиотеки в /usr/lib и в /lib должны быть упакованы отдельно в специальный библиотечный пакет с именем, содержащим название основной библиотеки и major (или soname, см. далее). Эти пакеты не должны содержать никаких бинарных файлов, которые должны быть в другом пакете. Пакеты могут содержать другие файлы (например, документацию или лицензию) при условии, что эти файлы установлены по адресу, специфичному для пакета (например, libfoo2 может установить что-то в /usr/share/doc/libfoo2/). Цель состоит в том, чтобы установить libfoo1 и libfoo2 в одну систему.

Прежде всего фундаментально, что исходные rpm сохраняют одно имя без какого-либо major номера, так что git репозиторий содержит только одну ветку каждого пакета.

Когда дистрибутив должен иметь две версии одной библиотеки одновременно (например, qt1 и qt2), то исходные rpm будут разделены, чтобы мы могли включить обе версии в дистрибутив в виде двух разных, независимо поддерживаемых пакетов.

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

  • Исходный пакет:
    • foo-2.3.4-4-rosa2012.src.rpm
  • Бинарные пакеты:
    • foo-2.3.4-4-rosa2012.arch.rpm
    • libfoo2-2.3.4-4-rosa2012.arch.rpm
    • libfoo-devel-2.3.4-4-rosa2012.arch.rpm

Если foo-2.3.4-4-rosa2012.src.rpm создаёт несколько библиотек, то эти библиотеки должны быть упакованы в отдельные файлы: libfoo2-2.3.4-4-rosa2012.arch.rpm, libbar2-2.3.4-4-rosa2012.arch.rpm и т.д. Однако devel файлы могут быть собраны в один пакет. Имя такого пакета может начинаться с lib, однако для 32-битных и 64-битных пакетов желательно иметь разные имена (например, foo-devel и foo64-devel). Обоснование: -devel пакеты не устанавливаются пользователем, поэтому разделение таких пакетов не влияет на пользователя, но может усложнить жизнь разработчику. Отдельные имена для 32-битных и 64-битных -devel пакетов позволяют устанавливать пакеты обеих архитектур в одной системе.

Если апстримное имя само по себе начинается с lib (например, libxml2), то пакет с бинарными файлами можно назвать libfoo-utils или libfoo-tools или как-то похоже, чтобы можно было отличить его от пакета библиотеки.

Названия для x86_64

  • Бинарные пакеты:
    • foo-2.3.4-4-rosa2012.x86_64.rpm
    • lib64foo2-2.3.4-4-rosa2012.x86_64.rpm
    • lib64foo-devel-2.3.4-4-rosa2012.x86_64.rpm

Чтобы было проще, используйте %mklibname:

%mklibname

Макрос %mklibname используется для создания имён библиотечных пакетов:

  •  %mklibname [-d [-s]] name [[api] major]
    • -d - создание имени для devel пакета
    • -s - создание имени для static пакета (использовать вместе с -d)
    • name - имя библиотеки (обратите внимание, что если именем библиотеки является libfoo, то надо вводить foo, а не libfoo)
    • major - основное число, которое должно быть добавлено в имя (не использовать вместе с -d, кроме особых случаев, упомянутых отдельно ниже)
    • api - если библиотека имеет, например, SONAME libfoo-1.2.so.4, то api будет 1.2, а major - 4. Результатом будет libfoo1.2_4

Примеры использования:

  •  %mklibname foo 5 => libfoo5
  •  %mklibname -d foo => libfoo-devel
  •  %mklibname -d -s foo => libfoo-static-devel

Файлы *.la

Современные libtool отлично работают без *.la файлов, поэтому эти файлы по-умолчанию отбрасываются spec-helper во время сборки. В настоящее время известно несколько исключений, которые включены в код spec-helper. Если вы считаете, что нашли ещё одно исключение, свободно обращайтесь к мейнтейнерам rpmbuild.

Особые случаи

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

  • Не забывайте всегда проверять soname библиотек (objdump -x libfoo.so.1 | grep SONAME), потому что некоторые soname содержат номер версии библиотеки. Например, libfoo-1.2.so.4. В этом случае пакет должен быть назван libfoo1.2_4-1.2.4-rosa2012.
  • Пакеты, оканчивающиеся номером, должны быть снабжены "_" перед major. Например, libfoo23_4-1.2-rosa2012 (в этом случае soname будет libfoo23.so.4).
  • Нет необходимости помещать каждую библиотеку в отдельный пакет: если пакет содержит несколько библиотек, имя можно взять из основной библиотеки пакета. Если есть проблемы с хранением библиотек в одном пакете (например, их major может отличаться), пакет должен быть разделён.
    • При разбиении библиотек, которые ранее были в одном пакете, вам может потребоваться добавить Obsoletes/Conflicts в новые пакеты, чтобы попросить Urpmi поместить их в одну транзакцию.
  • Если в дистрибутиве поддерживаются несколько версий пакета с разными major, или будущий релиз получится несовместимым по major (перестройка соответствующих pkgs не является достаточной, а требуемые изменения слишком велики) с текущей версией (например, QT3/QT4/QT5), то имя devel пакета должно содержать major. В предыдущем же случае devel субпакет новой версии обычно не содержит major, а только старые версии.
  • Некоторые приложения (например, KDE ones) содержат динамически загружаемые модули, которые не являются библиотеками. Обычно эти модули помещают в основной субпакет приложения. Но иногда лучше включать такие модули в библиотечный пакет, если их установка обычно требуется при использовании библиотеки (чтобы каждое приложение, использующее библиотеку, не требовало добавить руководство по модулям). В целом, решения должны приниматься индивидуально. Однако, если модули включены в библиотечный пакет, они должны попасть в каталог с версией (например, /usr/lib/foo-2/module.so для пакета libfoo2) , чтобы установка нескольких версий библиотеки была возможной.

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

Измените имя devel пакета с %libname-devel на %mklibname %name -d (без %major, хотя обычно с %api, если есть), как показано выше, и добавьте Obsoletes для предыдущего имени (%mklibname %name 2 -d или %{_lib}%{name}2-devel, где 2 - major устаревшего devel пакета). Для static-devel пакетов надо произвести замену на %mklibname %name -d -s. Если есть сомнения, свободно спрашивайте в списках рассылки ROSA.

Provides и conflicts

Пакет -devel должен как минимум содержать %name-devel = %version-%release. Если исходное имя тарбола отличается от %name, то вы также должны добавить tarballname-devel = %version-%release, для совместимости с другими rpm-системами. Если в дистрибутиве содержится несколько версий библиотеки, только последняя должна называться %name-devel. Предыдущие версии должны иметь в названии, например, %name%major-devel или %name%api-devel. Но мейнтейнер также может выбрать %name%major-devel или %name%api-devel и для нового пакета, если следующий major по исходному коду окажется несовместимым (см. Особые случаи выше).

Важно понимать, что включение Provides без информации о версии делает невозможным последующее включение информации о версии. Например, "Provides: foo-devel" - НЕ годится. Пожалуйста, используйте "Provides: foo-devel = 1.2.4-3-rosa2012".

Если в дистрибутиве содержится несколько версий библиотеки, и использовано исключение в виде добавления major в название lib -devel пакета, вам нужно добавить conflicts с другими devel пакетами, если их нельзя устанавливать параллельно. Это часто бывает, когда major изменился без переименования заголовочных файлов.


Добавление старой версии в дистрибутив

Если пакет обновлён до нового major, и будет замечено, что он не совместим с исходным кодом предыдущего релиза, и пользователи библиотеки не смогут быть прямо пропатчены для использования нового API, то старая библиотека должна поддерживаться параллельно с новой. Процесс создания на примере пакета foo, который обновляется до major 3:

  1. Копируется git foo непосредственно перед обновлением foo2 до major 3. Также изменяется Name на foo2 и имя спек-файла на foo2.spec.
  2. Добавляется 2 (major) к имени devel пакета, например, libfoo2-devel вместо libfoo-devel. Это можно осуществить добавлением параметра %major в %mklibname для %devname.
  3. Редактируются все provides, чтобы в них был major. Например, %name-devel или foo%major-devel.
  4. Добавляется Conflicts: foo-devel, если пакет конфликтует с новым devel пакетом.

Внесения каких-либо изменений в .spec для новой версии не требуется.

Пример

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

# api - это часть имени библиотеки перед .so
%define api 1.2
# major - это часть имени библиотеки после .so
%define major 1
%define libname %mklibname %{name} %{api} %{major}
%define devname %mklibname %{name} -d

#(!) summary только для SRPM
Summary:        C++ interface for popular GUI library gtk+
Name:           gtkmm
Version:        1.2.4
Release:        1

%description
#Полное и общее описание всего пакета. (Это будет только
#для SRPM)

#----------------------------------------------------------------------------

#Главный пакет (содержит только .so.[major].)
%package -n %{libname}
#(!) summary только для главной lib RPM
Summary:        Main library for gtkmm 
Group:          System/Libraries

%description -n %{libname}
This package contains the library needed to run programs dynamically
linked with gtkmm.

%files -n %{libname}
# ..
# содержит major (и api, если есть) в списке файлов, чтобы захватить
изменения при обновлении версии
%{_libdir}/lib-%{api}.so.%{major}*

#----------------------------------------------------------------------------

%package -n %{devname}
Summary:        Headers for developing programs that will use Gtk--
Group:          Development/GNOME and GTK+
Requires:       %{libname} = %{EVRD}
#(!) Не обязательно, так как мы предпочитаем использовать зависимости типа pkgconfig.
# Но если в библиотеке нет файлов pkgconfig, это необходимо
Provides:       %{name}-devel = %{EVRD}

%description -n %{devname}
This package contains the headers that programmers will need to develop
applications which will use Gtk--, the C++ interface to the GTK+ (the Gimp
ToolKit) GUI library.

%files -n %{devname}
# ..
%{_bindir}/gtkmm-config
%{_includedir}/*.h
%{_libdir}/*.so

#----------------------------------------------------------------------------

См. также

Policy for KDE 4 Libraries

Idea.png
Примечание
Эта Политика основана на Политике Оформления Библиотек Mandriva.
Источник — «http://wiki.rosalab.com/ru/index.php?title=Политика_оформления_библиотек&oldid=17525»