[devel] I: SharedLibsPolicy update (libjxl update)
Anton Farygin
rider на basealt.ru
Ср Фев 28 08:53:08 MSK 2024
On 28.02.2024 00:17, Vitaly Lipatov wrote:
> Но я бы предложил обсудить применение требования policy не ко всем
> библиотекам, а ко всем, имеющим больше 3 (т.е. много) пользователей
> (пакетов) в репозитории.
Проблема не только в количестве клиентов у библиотеки, но и в их качестве.
Большинство проблем вылезает с обновлением зависимых библиотек.
Ну, например:
libavcodec60 зависит от библиотеки (вымышленной) libeformat с soname 1
внутри пакета (и только от неё)
После этого происходит обновление:
появляется пакет libavcodec61 и одновременно внутри libeformat
появляется библиотека с soname 2, с которой и собирается этот libavcodec61
Сразу после этого перестаёт соблюдаться условие о возможном
одновременном существовании в одной системе libavcodec60 и libavcodec61
для безболезненного обновления, т.к. libeformat такого же требования не
соблюдает и не может быть установлен в одну систему одновременно со
старой версией.
Т.е. - все библиотеки, с которыми линкуются популярные библиотеки -
должны быть собраны в соответствии с SharedLibsPolicy на всём дереве
зависимостей, иначе когда-то в каком-то из пакетов вылезет проблема с
обновлением.
Какое-то время можно жить в ситуации, когда все сразу и одновременно не
соблюдают SharedLibsPolicy. Но тогда должны исключаться точечные
обновления и установка пакетов, не собранных в репозиторий.
Mixed конфигурации гарантированно ломаются на длительном промежутке
времени и для их обновления будут придумываться разные костыли (например
этот костыль):
https://packages.altlinux.org/ru/p10/srpms/exiv2/3040397079046255719
существующий только в версии для p10:
https://packages.altlinux.org/ru/p10/binary/libexiv2_27/x86_64/3040397706222904071
И всё это ещё усугубляет то, что корректное обновление с пакета,
собранного не по правилам SharedLibsPolicy до пакета, собранного по этим
правилам идеально и легко проходит только в случае смены soname.
Иначе надо будет придумывать Obsoletes, который работают тоже хреново:
https://packages.altlinux.org/ru/p10/srpms/exiv2/specfiles/3040397079046255719#line-53
т.е. в данном примере обсолетят все libexiv2 с версией <= 0.27.7-alt1.1
особенно не разбираясь с историей смены soname. И поведение apt в такой
ситуации при Major обновлении с какого-то p9 или p8 становится
непредсказуемым из-за весового алгоритма при принятии решений об
удалении пакетов.
Подробная информация о списке рассылки Devel