Re: [devel] I: SharedLibsPolicy update (libjxl update)

[Anton Farygin <rider@basealt.ru>]

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 становится 
непредсказуемым из-за весового алгоритма при принятии решений об 
удалении пакетов.