[devel] I: SharedLibsPolicy update (libjxl update)

[devel] I: SharedLibsPolicy update (libjxl update)

[Anton Farygin]

Всем привет.

Глядя на то, с каким трудом Юра собирал 
https://packages.altlinux.org/ru/sisyphus/srpms/libjxl/ я понял, что 
SharedLibsPolicy тяжела для осознания даже опытными ментейнерами с 
большим стажем.

Дополнил SharedLibsPolicy двумя условиями, про выполнение которых часто 
забывают ментейнеры, делая ошибки сборки shared библиотек в отдельные 
подпакеты.

https://www.altlinux.org/index.php?title=Shared_Libs_Policy&type=revision&diff=78668&oldid=76336


А с libjxl - последнее изменение пакета:

https://packages.altlinux.org/ru/sisyphus/srpms/libjxl/3043434039706690595

решает сиюминутный вопрос обновления, то гарантированно приведёт к 
проблеме с обновлениями при выходе libjxl с новым soname.

К сожалению, я не могу линковаться с такой библиотекой в своих пакетах. 
Но поддержка формата JXL важна для репозитория. Думаю что надо добить 
SharedLibsPolicy до стадии утверждённой политики и внести проверки на 
обязательное соответствие policy в сборочную систему.

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

[Ruslandh]

[-- Attachment #1.1.1: Type: text/plain, Size: 2488 bytes --]

23.02.2024 12:56, Anton Farygin пишет:
> Всем привет.
> 
> Глядя на то, с каким трудом Юра собирал 
> https://packages.altlinux.org/ru/sisyphus/srpms/libjxl/ я понял, что 
> SharedLibsPolicy тяжела для осознания даже опытными ментейнерами с 
> большим стажем.
> 
> Дополнил SharedLibsPolicy двумя условиями, про выполнение которых часто 
> забывают ментейнеры, делая ошибки сборки shared библиотек в отдельные 
> подпакеты.
> 
> https://www.altlinux.org/index.php?title=Shared_Libs_Policy&type=revision&diff=78668&oldid=76336
> 
> 
> А с libjxl - последнее изменение пакета:
> 
> https://packages.altlinux.org/ru/sisyphus/srpms/libjxl/3043434039706690595
> 
> решает сиюминутный вопрос обновления, то гарантированно приведёт к 
> проблеме с обновлениями при выходе libjxl с новым soname.
> 
> К сожалению, я не могу линковаться с такой библиотекой в своих пакетах. 
> Но поддержка формата JXL важна для репозитория. Думаю что надо добить 
> SharedLibsPolicy до стадии утверждённой политики и внести проверки на 
> обязательное соответствие policy в сборочную систему.

Я не очень в тему, но что-то у нас не так.
https://bugzilla.altlinux.org/49495
Qt обновилось, приложения продолжают пересобираться в тестовом режиме с 
новым qt, но приложения, лежащие в репозитории всё равно собраны со 
старой версией qt.
По идее надо всем qt приложениям, которых  это может затронуть, надо 
повысить версию и пересобрать как пакет с новой версией, так как не 
уверен, что это будет так явно, как это с телеграм.




---------------------------------------------------
С уважением, Хихин Руслан


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 657 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[devel] I: Cannot mix incompatible Qt library (6.6.1) with this library (6.6.2)

[Ruslandh]

[-- Attachment #1.1.1: Type: text/plain, Size: 2527 bytes --]

23.02.2024 12:56, Anton Farygin пишет:
> Всем привет.
> 
> Глядя на то, с каким трудом Юра собирал 
> https://packages.altlinux.org/ru/sisyphus/srpms/libjxl/ я понял, что 
> SharedLibsPolicy тяжела для осознания даже опытными ментейнерами с 
> большим стажем.
> 
> Дополнил SharedLibsPolicy двумя условиями, про выполнение которых часто 
> забывают ментейнеры, делая ошибки сборки shared библиотек в отдельные 
> подпакеты.
> 
> https://www.altlinux.org/index.php?title=Shared_Libs_Policy&type=revision&diff=78668&oldid=76336
> 
> 
> А с libjxl - последнее изменение пакета:
> 
> https://packages.altlinux.org/ru/sisyphus/srpms/libjxl/3043434039706690595
> 
> решает сиюминутный вопрос обновления, то гарантированно приведёт к 
> проблеме с обновлениями при выходе libjxl с новым soname.
> 
> К сожалению, я не могу линковаться с такой библиотекой в своих пакетах. 
> Но поддержка формата JXL важна для репозитория. Думаю что надо добить 
> SharedLibsPolicy до стадии утверждённой политики и внести проверки на 
> обязательное соответствие policy в сборочную систему.

Я не очень в тему, но что-то у нас не так.
https://bugzilla.altlinux.org/49495
https://bugzilla.altlinux.org/49498

Qt обновилось, приложения продолжают пересобираться в тестовом режиме с 
новым qt, но приложения, лежащие в репозитории всё равно собраны со 
старой версией qt.
По идее надо всем qt приложениям, которых  это может затронуть, надо 
повысить версию и пересобрать как пакет с новой версией, так как не 
уверен, что это будет так явно, как это с телеграм.




---------------------------------------------------
С уважением, Хихин Руслан


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 659 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

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

[Dmitry V. Levin]

On Fri, Feb 23, 2024 at 12:56:10PM +0300, Anton Farygin wrote:
[...]
> Дополнил SharedLibsPolicy двумя условиями, про выполнение которых часто 
> забывают ментейнеры, делая ошибки сборки shared библиотек в отдельные 
> подпакеты.
> 
> https://www.altlinux.org/index.php?title=Shared_Libs_Policy&type=revision&diff=78668&oldid=76336

Добавленный пример с libxmlb - это скорее пример того, как не надо делать:

$ rpmquery -Rp Sisyphus/files/x86_64/RPMS/libxmlb2-0.3.14-alt1.x86_64.rpm |grep ^libxmlb
libxmlb-common = 0.3.14-alt1:sisyphus+329788.100.1.1
$ rpmquery -Rp Sisyphus/files/x86_64/RPMS/libxmlb-common-0.3.14-alt1.x86_64.rpm |grep ^libxmlb
libxmlb2 = 0.3.14-alt1:sisyphus+329788.100.1.1
$ rpmquery -lp Sisyphus/files/x86_64/RPMS/libxmlb-common-0.3.14-alt1.x86_64.rpm |grep /bin/
/usr/bin/xb-tool
$ rpmpeek Sisyphus/files/x86_64/RPMS/libxmlb-common-0.3.14-alt1.x86_64.rpm \
  readelf -d ./usr/bin/xb-tool |grep libxmlb
 0x0000000000000001 (NEEDED)             Shared library: [libxmlb.so.2]


-- 
ldv

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

[Anton Farygin]

On 26.02.2024 20:14, Dmitry V. Levin wrote:
> On Fri, Feb 23, 2024 at 12:56:10PM +0300, Anton Farygin wrote:
> [...]
>> Дополнил SharedLibsPolicy двумя условиями, про выполнение которых часто
>> забывают ментейнеры, делая ошибки сборки shared библиотек в отдельные
>> подпакеты.
>>
>> https://www.altlinux.org/index.php?title=Shared_Libs_Policy&type=revision&diff=78668&oldid=76336
> Добавленный пример с libxmlb - это скорее пример того, как не надо делать:
>
> $ rpmquery -Rp Sisyphus/files/x86_64/RPMS/libxmlb2-0.3.14-alt1.x86_64.rpm |grep ^libxmlb
> libxmlb-common = 0.3.14-alt1:sisyphus+329788.100.1.1
> $ rpmquery -Rp Sisyphus/files/x86_64/RPMS/libxmlb-common-0.3.14-alt1.x86_64.rpm |grep ^libxmlb
> libxmlb2 = 0.3.14-alt1:sisyphus+329788.100.1.1
> $ rpmquery -lp Sisyphus/files/x86_64/RPMS/libxmlb-common-0.3.14-alt1.x86_64.rpm |grep /bin/
> /usr/bin/xb-tool
> $ rpmpeek Sisyphus/files/x86_64/RPMS/libxmlb-common-0.3.14-alt1.x86_64.rpm \
>    readelf -d ./usr/bin/xb-tool |grep libxmlb
>   0x0000000000000001 (NEEDED)             Shared library: [libxmlb.so.2]

Спасибо. Надо ещё и эту ситуацию описать в Policy.

Для тех, кто не понял - у библиотеки есть зависимость на common пакет, 
но и у common пакета есть зависимость на библиотеку и это фактически 
блокирует возможность одновременной установки пакетов с библиотеками 
разных версий.

В данном случае нужно сделать отдельный подпакет tools, на который у 
библиотеки не будет зависимости.

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

[Vitaly Lipatov]

Anton Farygin писал(а) 23.2.24 12:56:
> Всем привет.
> 
> Глядя на то, с каким трудом Юра собирал 
> https://packages.altlinux.org/ru/sisyphus/srpms/libjxl/ я понял, что 
> SharedLibsPolicy тяжела для осознания даже опытными ментейнерами с 
> большим стажем.
> 
> Дополнил SharedLibsPolicy двумя условиями, про выполнение которых часто 
> забывают ментейнеры, делая ошибки сборки shared библиотек в отдельные 
> подпакеты.
> 
...
> Думаю что надо добить SharedLibsPolicy до стадии утверждённой политики 
> и внести проверки на обязательное соответствие policy в сборочную 
> систему.

Согласен, что для массово используемых (т.е. известных) библиотек это 
просто необходимо, особенно когда они имеют внешних пользователей или 
стали де факто частью Linux-системы.

Но я бы предложил обсудить применение требования policy не ко всем 
библиотекам, а ко всем, имеющим больше 3 (т.е. много) пользователей 
(пакетов) в репозитории.
Предполагаю, что существует много как бы внутренних библиотек, 
упакованных в пакеты lib*, потому что таковы требования — выделять 
библиотеки, даже если у них и нет отдельных пользователей. И для них 
лишние сложности ни к чему.

Кстати говоря, у нас не все пакеты с библиотеками имеют префикс lib, а 
мы уже хотим суффикс обязательный сделать. Например, вот zlib, bzlib.

Или в проверке на соответствие policy будет добавлен список исключений?

Также вот, например, libxxhash:
$ epm --short wd libxxhash
  $ apt-cache whatdepends libxxhash
libxxhash-devel
telegram-desktop
texlive
stress-ng
rsync
rpcs3
radare2
python3-module-xxhash
lighttpd
kitty
flycast
dolphin-emu
borg
libblack_hole_solver1

Вроде бы пора добавлять версию? С другой стороны, мы долгое время 
отличались от других систем, что они добавляли soname в название пакета, 
а мы нет.

Кажется, что основной критерий — это то, возможно ли одновременное 
существование актуальных приложений, требующих разные версии библиотек.
И если при наличии замкнутого репозитория долгое время удавалось это 
обходить удалением пакетов, обновлением всех под новую версию (с 
проблемами), то при наличии внешних пользователей к необходимости 
присутствия в системе всех ожидаемых ими библиотек (а это может быть и 
5-7 лет существования приложения) стоит отнестись серьёзнее.
Например, допускать одновременное существование в репозитории libssl1.1 
и libssl3.

Или вот например правильно собрать libevent:
https://bugzilla.altlinux.org/47040

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

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

[Anton Farygin]

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

Re: [devel] I: SharedLibsPolicy update (openssl1.1 & openssl3)

[Anton Farygin]

On 28.02.2024 00:17, Vitaly Lipatov wrote:
> в системе всех ожидаемых ими библиотек (а это может быть и 5-7 лет 
> существования приложения) стоит отнестись серьёзнее.
> Например, допускать одновременное существование в репозитории 
> libssl1.1 и libssl3. 

Вот здесь есть одна проблема, широко известная в узких кругах.

У библиотек могут быть конфигурационные файлы и плагины.

В хороших качественных проектах обычно они версионированы. Но в 
libcrypto они упакованы сейчас одинаковые:

https://packages.altlinux.org/ru/sisyphus/files/?q=%2Fetc%2Fopenssl%2Fopenssl.cnf

Хотя чисто теоретически они не обязаны быть одинаковыми и даже более 
того имеют право быть разными.

Хотя, по идее эти libcrypto1.1 и libcrypto3 не должны конфликтовать по 
файлам. Но какое то время они были идентичными и rpm пропускал такую 
конфигурацию.

А сейчас есть вот такая ошибка:

https://bugzilla.altlinux.org/48298

Честно не знаю как её будет решать ментейнер.

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

[Paul Wolneykien]

В Wed, 28 Feb 2024 00:17:37 +0300
Vitaly Lipatov <lav@altlinux.ru> пишет:

> Anton Farygin писал(а) 23.2.24 12:56:
> ...
> > Думаю что надо добить SharedLibsPolicy до стадии утверждённой политики 
> > и внести проверки на обязательное соответствие policy в сборочную 
> > систему.  
> 
> Согласен, что для массово используемых (т.е. известных) библиотек это 
> просто необходимо, особенно когда они имеют внешних пользователей или 
> стали де факто частью Linux-системы.

  Мне кажется, что нужно более веское обоснование, чем "просто
необходимо". На вики, например, есть такое:

  https://www.altlinux.org/Shared_Libs_Policy_and_updates

  Процитирую. "При проблемах обновления с бранча на бранч возможность
точечных обновлений чрезвычайно расширяется" ... "Например, возможность
обновить один новый пакет foo, зависящий от libexiv2_77 не затронет другой
старый пакет bar, который зависит от старой версии libexiv2_11, которой уже
нет в новом репозитории, но еще есть в системе."

  Кажется, что SharedLibsPolicy должна решить проблему точечных
обновлений. Но с чем на самом деле сталкивается пользователь пакета
bar, решивший поставить foo из нового бранча? В 90% случаев блокер ---
это libc! Из-за того, что foo собран с новой libc, последнюю нужно
обновить, а это значит --- вынести всю или почти всю старую систему,
включая, конечно, и пакет bar. Так для чего заострять внимание на
частной зависимости от libexiv, когда это --- второстепенная проблема?

  В связи с этим, если у наших пользователей есть необходимость
использовать программы из старых бранчей, я бы подумал над тем,
как предоставить им возможность разворачивать старую базовую систему
(p7, p8, p9, ...) в chroot, ставить туда пакеты и запускать эти
программы "бесшовно", то есть на актуальном десктопе. Но это, очевидно,
тема отдельного обсуждения.

> ...
> Кажется, что основной критерий — это то, возможно ли одновременное 
> существование актуальных приложений, требующих разные версии библиотек.

  Предлагаю сперва разобраться, откуда берутся такие актуальные приложения
и почему мы должны считать их актуальными? Какие здесь возможные причины?

  Если у приложения просто "тормозной" апстрим, то по факту такой проект
почти наверняка неподдерживаемый. Можно ли считать его актуальным?

  Другой вариант: апстрим вполне живой, но он не поспевает за обновлением
библиотеки в Сизифе. На мой взгляд, такая ситуация может означать, что
мэйнтейнер библиотеки в Сизифе слишком торопится её обновлять: к примеру,
собирает development, а не stable версию. Но здесь уместно будет спросить,
а нужно ли так торопиться? Ведь сборка не утверждённой сообществом версии
известной, широко используемой библиотеки приносит с собой (кроме проблем с
совместимостью с приложениями) неизвестные уязвимости. Тут мы подходим к
самому главному.

  Если мы, как пишет Виталий ниже, идём к "необходимости присутствия
в системе всех ожидаемых ими [версий] библиотек (а это может быть и 5-7 лет
существования приложения)", то, очевидно, это будет система, в которой
собраны все известные CVE за 5--7 лет!

  Правда, есть такая штука, как security bugfixes. То есть возможен такой
случай, когда сосуществует несколько версий библиотеки и все эти версии
снабжаются исправлениями безопасности. На мой взгляд, это именно тот
_единственный_ случай, когда допустимо одновременное наличие нескольких
версий известной библиотеки. Однако этот случай также отличается от того,
что советует SharedLibsPolicy. Что на практике означает наличие
security bugfixes для разных версий библиотеки? Это означает, что
апстрим библиотеки, а не только её мэйнтейнер в Сизифе, _поддерживает_
несколько _стабильных_ версий библиотеки: к примеру, текущую и LTS.
Но поддержка многоверсионности такого типа означает, что в Сизифе должно
быть несколько "полноценных" пакетов с разной версией библиттеки:
"полноценных" --- значит, должно быть несколько исходных пакетов,
каждый для своей версии, которые регулярно обновляются. Если я правильно
понял SharedLibsPolicy, то она этого не требует (хотя и не противоречит).

  Так что основной критерий наличия нескольких не конфликтующих пакетов
с библиотекой, на мой взгляд --- это одновременная поддержка нескольких
версий в апстриме. Только в этом случае совершенно понятно, откуда
берутся _актуальные_ версии приложений, требующие разные версии библиотеки.
И только в этом случае можно надеяться на контролируемое число CVE.
И, кстати, только в этом случае не будет проблемы с конфигурационными
файлами (то, о чём написал Антон в другом письме).

  Теперь насчёт сторонних приложений:

> И если при наличии замкнутого репозитория долгое время удавалось это 
> обходить удалением пакетов, обновлением всех под новую версию (с 
> проблемами), то при наличии внешних пользователей к необходимости 
> присутствия в системе всех ожидаемых ими библиотек (а это может быть и 
> 5-7 лет существования приложения) стоит отнестись серьёзнее.
> Например, допускать одновременное существование в репозитории libssl1.1 
> и libssl3.

  Мне кажется относительно "внешних пользователей" библиотеки, то есть
к внешних программ, вполне можно задать те же вопросы, что и
относительно программ внутренних (сизифных). Почему они "запали" на
конкретную (старую) версию библиотеки? Что это означает в смысле CVE?
Должна ли программная платформа потворствовать этому? Не исключено,
конечно, что это мэйнтейнер библиотеки поторопился (собрал devel вместо
stable).

  Мне кажется, что для тех внешних программ, которые _хотят_ собираться
под нашу платформу, вполне логично использовать актуальные версии
библиотек. А для остальных, которых платформа как платформа не
интересует, и которые хотят чтобы "просто работало", вполне допустим,
мне кажется, подход Flatpack (то есть, все библиотеки носит с собой).
Понятно, что такое стороннее приложение, вместе со старыми версиями
библиотек, приносит и известные уязвимости. Но по крайней мере эти
старые библиотеки тогда не являются частью программной платформы.

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

[Dmitry V. Levin]

On Wed, Feb 28, 2024 at 11:03:45PM +0300, Paul Wolneykien wrote:
[...]
> обновлений. Но с чем на самом деле сталкивается пользователь пакета
> bar, решивший поставить foo из нового бранча? В 90% случаев блокер ---
> это libc! Из-за того, что foo собран с новой libc, последнюю нужно
> обновить, а это значит --- вынести всю или почти всю старую систему,

Нет, не значит.


-- 
ldv

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

[Sergey V Turchin]

On Wednesday, 28 February 2024 23:03:45 MSK Paul Wolneykien wrote:

[...]
> Но с чем на самом деле сталкивается пользователь пакета
> bar, решивший поставить foo из нового бранча?
Это вообще нипричём.

[...]
> Так для чего заострять внимание на
> частной зависимости от libexiv
Потому, что это реальная проблема.
https://bugs.altlinux.org/49392

[...]

-- 
Regards, Sergey.

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

[Paul Wolneykien]

В Thu, 29 Feb 2024 10:56:19 +0300
Sergey V Turchin <zerg@altlinux.org> пишет:

> On Wednesday, 28 February 2024 23:03:45 MSK Paul Wolneykien wrote:
> 
> [...]
> > Но с чем на самом деле сталкивается пользователь пакета
> > bar, решивший поставить foo из нового бранча?  
> Это вообще нипричём.
> 
> [...]
> > Так для чего заострять внимание на
> > частной зависимости от libexiv  
> Потому, что это реальная проблема.
> https://bugs.altlinux.org/49392

  Хорошо, понял. А вариант, при котором в системе остаётся пакет
со старой библиотекой и одновременно устанавливается пакет с
новой библиотекой, когда-нибудь рассматривался на уровне
модификации apt? Я имею в виду, чтобы буквально в системе разрешить
одновременную установку нескольких версий пакета с одним и тем
же именем, при условии, что они не имеют файловых конфликтов?

  Просто, по беглым подсчётам, в Сизифе сейчас ~700 пакетов, которые
формально не соблюдают SharedLibsPolicy (в названии пакета нет
версии), но при этом в эти пакеты упакованы только файлы
*.so.* --- то есть, гипотетически, они могли бы быть установлены
в системе совместно со своими же старыми версиями, если бы
такое умел apt. Мне кажется, для пользователя это было бы
нагляднее и прозрачнее, чем пакеты с похожими, но не одинаковыми
именами. И возможно, это было бы проще, чем переводить все эти
пакеты на SharedLibsPolicy.

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

[Sergey V Turchin]

On Thursday, 29 February 2024 13:46:40 MSK Paul Wolneykien wrote:

[...]
> > > Так для чего заострять внимание на
> > > частной зависимости от libexiv
> > 
> > Потому, что это реальная проблема.
> > https://bugs.altlinux.org/49392
> 
>   Хорошо, понял. А вариант, при котором в системе остаётся пакет
> со старой библиотекой и одновременно устанавливается пакет с
> новой библиотекой, когда-нибудь рассматривался на уровне
> модификации apt? Я имею в виду, чтобы буквально в системе разрешить
> одновременную установку нескольких версий пакета с одним и тем
> же именем, при условии, что они не имеют файловых конфликтов?
В конретном случае конфликт есть. И в других многих будут.

[...]

-- 
Regards, Sergey.

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

[Anton Farygin]

On 29.02.2024 13:46, Paul Wolneykien wrote:
> Просто, по беглым подсчётам, в Сизифе сейчас ~700 пакетов, которые
> формально не соблюдают SharedLibsPolicy (в названии пакета нет
> версии), но при этом в эти пакеты упакованы только файлы
> *.so.* --- то есть, гипотетически, они могли бы быть установлены
> в системе совместно со своими же старыми версиями, если бы
> такое умел apt. Мне кажется, для пользователя это было бы
> нагляднее и прозрачнее, чем пакеты с похожими, но не одинаковыми
> именами. И возможно, это было бы проще, чем переводить все эти
> пакеты на SharedLibsPolicy.

нет, у apt и так сложная и запутанная логика принятия решений об 
установке пакетов и делать её ещё сложнее точно не нужно.

Гораздо проще поправить эти самые 700 пакетов, к тому же это можно 
делать плавно и в течении нескольких лет.

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

[manowar]

23 февраля 2024 г. 12:56:10 GMT+03:00, Anton Farygin <rider@basealt.ru> пишет:
>Всем привет.
>
>Глядя на то, с каким трудом Юра собирал https://packages.altlinux.org/ru/sisyphus/srpms/libjxl/ я понял, что SharedLibsPolicy тяжела для осознания даже опытными ментейнерами с большим стажем.

А можно ещё пояснить такой момент. Почему нельзя именовать версии пакетов libname, libname2, libname3 и т. д.? Я к тому, что несовместимое изменение ABI может ведь никогда не произойти, мы об этом заранее не знаем. Мне кажется излишним заранее предполагать такой случай и закладывать в название пакета "1". А если слом ABI всё-таки произойдёт, тогда уже прибавить сразу " 2", а старую версию оставить без цифры.


>Дополнил SharedLibsPolicy двумя условиями, про выполнение которых часто забывают ментейнеры, делая ошибки сборки shared библиотек в отдельные подпакеты.
>
>https://www.altlinux.org/index.php?title=Shared_Libs_Policy&type=revision&diff=78668&oldid=76336
>А с libjxl - последнее изменение пакета:
>
>https://packages.altlinux.org/ru/sisyphus/srpms/libjxl/3043434039706690595
>
>решает сиюминутный вопрос обновления, то гарантированно приведёт к проблеме с обновлениями при выходе libjxl с новым soname.
>
>К сожалению, я не могу линковаться с такой библиотекой в своих пакетах. Но поддержка формата JXL важна для репозитория. Думаю что надо добить SharedLibsPolicy до стадии утверждённой политики и внести проверки на обязательное соответствие policy в сборочную систему.
>
>
>_______________________________________________
>Devel mailing list
>Devel@lists.altlinux.org
>https://lists.altlinux.org/mailman/listinfo/devel
-- Отправлено через /e/OS Mail.

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

[Mikhail Efremov]

[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

On Fri, 22 Mar 2024 17:29:49 +0300 manowar@altlinux.org wrote:
> 23 февраля 2024 г. 12:56:10 GMT+03:00, Anton Farygin <rider@basealt.ru> пишет:
> >Всем привет.
> >
> >Глядя на то, с каким трудом Юра собирал https://packages.altlinux.org/ru/sisyphus/srpms/libjxl/ я понял, что SharedLibsPolicy тяжела для осознания даже опытными ментейнерами с большим стажем.  
> 
> А можно ещё пояснить такой момент. Почему нельзя именовать версии пакетов libname, libname2, libname3 и т. д.? Я к тому, что несовместимое изменение ABI может ведь никогда не произойти, мы об этом заранее не знаем. Мне кажется излишним заранее предполагать такой случай и закладывать в название пакета "1". А если слом ABI всё-таки произойдёт, тогда уже прибавить сразу " 2", а старую версию оставить без цифры.

+1. Я, собственно, именно так с библиотеками и делаю.

-- 
WBR, Mikhail Efremov

[-- Attachment #2: Цифровая подпись OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Sergey V Turchin]

On Friday, 22 March 2024 17:54:58 MSK Mikhail Efremov wrote:

[...]
> > тогда уже прибавить сразу " 2", а старую версию оставить без цифры.
> +1. Я, собственно, именно так с библиотеками и делаю.
Это шаг к рези^Wвероятности тупо забыть переименовать при смене soname.

-- 
Regards, Sergey.

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

[Anton Farygin]

On 22.03.2024 17:29, manowar@altlinux.org wrote:
> 23 февраля 2024 г. 12:56:10 GMT+03:00, Anton Farygin<rider@basealt.ru>  пишет:
>> Всем привет.
>>
>> Глядя на то, с каким трудом Юра собиралhttps://packages.altlinux.org/ru/sisyphus/srpms/libjxl/  я понял, что SharedLibsPolicy тяжела для осознания даже опытными ментейнерами с большим стажем.
> А можно ещё пояснить такой момент. Почему нельзя именовать версии пакетов libname, libname2, libname3 и т. д.? Я к тому, что несовместимое изменение ABI может ведь никогда не произойти, мы об этом заранее не знаем. Мне кажется излишним заранее предполагать такой случай и закладывать в название пакета "1". А если слом ABI всё-таки произойдёт, тогда уже прибавить сразу " 2", а старую версию оставить без цифры.

Ровно для того, что бы не забыть потом при изменении версии ABI сделать 
пакет с другим именем.

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

[Sergey V Turchin]

On Friday, 22 March 2024 18:26:06 MSK Anton Farygin wrote:

[...]
> Ровно для того, что бы не забыть потом при изменении версии ABI сделать
> пакет с другим именем.
+1
Я сразу делаю закладку в spec против забывания.

-- 
Regards, Sergey.