Просмотр кода страницы Shared Libs Policy Comments

[[Файл:Libpaper0.png|безрамки|right|link=Shared Libs Policy Versioning Example|Shared Libs Policy Versioning Example]]

Пошаговая инструкция по переходу на Shared Libs Policy при смене soname.

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

=== Обновление пошагово ===

Рассмотрим пошагово действия при обновлении на примере условного пакета libfoo, у которого в новой версии поменялся soname (имя библиотеки):
<code>libfoo.so.N -> libfoo.so.M</code>.

==== Обновление пакета libfoo ====
# Берем пакет libfoo из репозитория и обновляем его до новой версии.
# Меняем название бинарного пакета на libfooM.
## Для указания версии библиотеки добавляем в спек
##: <code>%define abiversion M</code>
##:и используем его в названии бинарного пакета:
##: <code>%package -n libfoo%abiversion</code>
##: и в секции %files:
##: <code>%_libdir/lib%name.so.%abiversion</code>
##:(последнее — для подстраховки от случайной смены soname при обновлении пакета).
<!--## Добавляем в libfooM
##: <code>Provides: libfoo = %version-%release</code>
##:(для совместимости с пакетами и пользователями, которые используют имя libfoo).-->
## Название пакета libfoo-devel оставляем неизменным
# Если в новом пакете libfooM будут пересечения по файлам со старым пакетом libfoo (например, был упакован файл /usr/bin/foo, который переехал в libfooM), проставляем у libfooM конфликт со старой версией:
#: <code>Conflicts: libfoo < 1.1.28-alt4</code>
#: (если пересечение есть и с собранным из libfooN пакетом, указываем <code><=</code> в Conflicts, но такую ситуацию желательно не допускать)

==== Добавление пакета libfooN ====
# Делаем копию пакета libfoo из репозитория (то есть старого) под названием libfooN.
# Отключаем в пакете сборку всего, что может конфликтовать по файлам с пакетами новой версии, ведь у нас цель обеспечить возможность одновременной установки libfooN и libfooM.
# Оставляем только подпакет libfoo (единственный, который будет формироваться при сборке).
# Для указания версии библиотеки добавляем в спек
#: <code>%define abiversion N</code>
#:и используем его в секции <code>%files -n libfoo</code>:
#: <code>%_libdir/lib%name.so.%abiversion</code>
#:(для подстраховки от случайной смены soname при обновлении пакета).
<!--#:и для бинарного пакета libfoo в
#: <code>Provides: libfoo%abiversion = %EVR</code>-->
# Указываем Legacy группу для пакета:
#: <code>Group: System/Legacy libraries</code>

=== Дополнительные пункты для самопроверки ===
# При взгляде на исходные пакеты: добавляется новый пакет libfooN (из него собирается бинарный libfoo<ref>libfoo, а не libfoo1, чтобы соблюсти условие о том, что библиотека не должна переезжать в пакет с другим названием.</ref>).
# При взгляде на бинарные пакеты: добавляется новый пакет libfooM (из него собирается бинарный libfooM и libfoo-devel)
# Если библиотека пакуется под SharedLibsPolicy, то в пакете с библиотекой не должно быть ничего, что может потом в дальнейшем начать конфликтовать с файлами из нового пакета этой библиотеки. То есть содержимое /usr/bin должно оказаться в %name-tools, а %_datadir/%name/ — в %name-common (условно).
# Следует придерживаться того правила, чтобы пакет с библиотекой не менял имя, поскольку существует вероятность<ref>
glebfm@: Я (как автор того изменения в apt, которое улучшило положение дел) всегда был уверен, что просто сильно уменьшилась вероятность. https://bugzilla.altlinux.org/show_bug.cgi?id=46837#c11</ref> того, что apt не сможет корректно обработать ситуацию, когда библиотека с конкретным soname переезжает в пакет с другим названием.
# При переходе на SharedLibsPolicy следует исправить все недостатки разбиения по подпакетам — смена soname удобный момент для этого.
# Добавлять в libfooM провайд <code>libfoo = %version-%release</code> не следует, поскольку для зависимостей между пакетами это только внесёт путаницу, а вручную обычно библиотеки не устанавливают (в отличие от devel-пакетов).



=== Причины для применения Shared Libs Policy ===
* Постепенная пересборка пакетов в репозитории при обновлении пакета.
*: Чтобы не общаться с другим мантейнерами на предмет разрешения пересборки их пакетов в вашем большом задании, вы по сути просто собираете новую библиотеку  в новый пакет, не нарушая целостность репозитория, а мантейнерам оставляете возможность чинить их пакеты, если они перестают собираться с новой версии библиотеки.
* Необходимость одновременного существования разных версий библиотек в репозитории.
*: Библиотека может быть очень известной (например, libpng) и сторонние бинарные программы могут быть привязаны к определённой версии библиотеки, не той,которая основная в репозитории.
* При проблемах обновления с бранча на бранч возможность точечных обновлений чрезвычайно расширяется, т.к. старые библиотеки со старыми SONAME вытеснять никто не будет. Например, возможность обновить один новый пакет foo , зависящий от libname2 не затронет другой старый пакет bar, который зависит от старой версии libname1, которой уже нет в новом репозитории, но еще есть в системе. Если бы пакет со старой и новой версией библиотеки назывался libname, то по цепочке потянулась бы вся борода из других библиотек и пакетов, наткнувшись на какую-нибудь другую проблему обновления.

=== Причины для неприменения Shared Libs Policy ===

* SharedLibsPolicy не применим, если пакет содержит множество других файлов, например с данными или плагинами, в пересекающихся каталогах (см. libsane в качестве примера). В этом случае мантейнеру придётся пересобрать в своём задании все зависящие пакеты.


=== Вынесение утилит в подпакет ===

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

К примеру,  от пакета libfooM ожидается собственно библиотека, а /usr/bin/foo должен быть упакован в отдельный подпакет, например libfoo-utils или просто foo, в зависимости от важности команды и их количества.

Такой пакет скорее всего будет иметь зависимость на libfoo, но пакет libfoo не должен зависеть от утилит (если библиотека вызывает утилиты, тогда разделение на подпакет не имеет смысла).

==== Польза от вынесения утилит в подпакет ====

* Чтобы не было файлового конфликта у любых релизов libfoo, libfooN, libfooM.
* Чтобы тот, кто устанавливал /usr/bin/foo, не потерял его в системе, когда /usr/bin/foo переедет из пакета libfoo в libfooM.
* Минимизация зависимостей пакета с библиотекой. Если /usr/bin/foo это скрипт на python, то в итоге у пакета с библиотекой раздуются зависимости.

=== Благодарности ===

За появление этой статьи большая благодарность Глебу, начавшему обсуждение<ref>https://lore.altlinux.org/devel/ZL7b3jkMiopSSuVX@glebfm.altlinux.org/</ref> и другим участникам:
* Gleb Fotengauer-Malinovskiy
* Mikhail Tergoev
* Alexey V. Vissarionov
* Sergey V Turchin
* Anton Farygin

=== Ссылки ===
<references/>

=== См. также ===
* https://www.altlinux.org/Shared_Libs_Policy
* https://www.altlinux.org/Soname
* https://www.altlinux.org/Filesystem_coherency_and_conflicts

[[Категория: Devel]]