Survolog: Создание для восстановления из предыдущей wiki

2025-04-09T13:36:17Z

Создание для восстановления из предыдущей wiki

Новая страница

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

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

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

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

* Исходный пакет:
** foo-2.3.4-4-rosa2012.src.rpm

* BБинарные пакеты:
** 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 (например, <code>libxml2</code>), то пакет с бинарными файлами можно назвать <code>libfoo-utils</code> или <code>libfoo-tools</code> или как-то похоже, чтобы можно было отличить его от пакета библиотеки.

==== Названия для 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

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

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

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

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

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

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

== Добавление предыдущей мажорной версии в дистрибутив ==
Если пакет обновлён до нового major, и будет замечено, что он не совместим с исходным кодом предыдущего релиза, и пользователи библиотеки не смогут быть прямо пропатчены для использования нового API, то старая библиотека должна поддерживаться параллельно с новой. Процесс создания на примере пакета foo, который обновляется до major 3:
# Копируется git foo непосредственно перед обновлением foo2 до major 3. Также изменяется <code>Name</code> на foo2 и имя спек-файла на <code>foo2.spec</code>.
# Добавляется 2 (major) к имени devel пакета, например, libfoo2-devel вместо libfoo-devel. Это можно осуществить добавлением параметра <code>%major</code> в <code>%mklibname</code> для <code>%devname</code>.
# Редактируются все Provides, чтобы в них был major. Например, <code>%name-devel</code> или <code>foo%major-devel</code>.
# Добавляется Conflicts: <code>foo-devel</code>, если пакет конфликтует с новым devel пакетом.

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

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

<pre>
# 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

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

</pre>

<hr>

[[Категория:Политики сборки пакетов]]

Политика оформления библиотек - История изменений

Survolog: Создание для восстановления из предыдущей wiki