Библиотеки в /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 создаёт несколько библиотек, то эти библиотеки должны быть упакованы в отдельные файлы: 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 или как-то похоже, чтобы можно было отличить его от пакета библиотеки.
Чтобы было проще, используйте %mklibname:
Макрос %mklibname используется для создания имён библиотечных пакетов:
Примеры использования:
Современные libtool отлично работают без *.la файлов, поэтому эти файлы по-умолчанию отбрасываются spec-helper во время сборки. В настоящее время известно несколько исключений, которые включены в код spec-helper. Если вы считаете, что нашли ещё одно исключение, свободно обращайтесь к мейнтейнерам rpmbuild.
Мы описали основную политику для пакетов библиотек, однако, могут произойти некоторые особые случаи, которые должны быть рассмотрены вдумчиво:
Измените имя 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.
Пакет -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:
Внесения каких-либо изменений в .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 #----------------------------------------------------------------------------