Re: [devel] переработанный документ SharedLibsPolicy (update 1)

[Vitaly Chikunov <vt@altlinux.org>]

On Fri, Aug 15, 2025 at 10:40:02AM +0300, Vitaly Chikunov wrote:
> On Fri, Aug 15, 2025 at 10:35:45AM +0400, Ivan A. Melnikov wrote:
> > On Fri, Aug 15, 2025 at 09:21:04AM +0300, Vitaly Chikunov wrote:
> > > On Thu, Aug 14, 2025 at 02:33:47PM +0400, Ivan A. Melnikov wrote:
> > > > On Thu, Aug 07, 2025 at 05:20:26PM +0300, Anton Farygin wrote:
> > > > [...]
> > > > > * Каждая несовместимая версия библиотеки должна быть в отдельном бинарном
> > > > > пакете.
> > > > > * Название пакета: `libfoo%abiversion`
> > > > > * Если имя библиотеки заканчивается на цифру, то используется подчёркивание:
> > > > > `libfoo_%abiversion`
> > > > > * В пакете не должно быть файлов с путями, не содержащими номер ABI.
> > > > 
> > > > Странная формулировка.
> > > > 
> > > > [...]
> > > > > == Как выбирать %abiversion ==
> > > > > 
> > > > > Если библиотека использует `soversion` — используем его как %abiversion.
> > > > > 
> > > > > Если `soversion` отсутствует или нестабилен — используем:
> > > > > 
> > > > > * возрастающее число: `libfoo0`, `libfoo1`
> > > > > * major-версию: `libqt3`, `libqt4`
> > > > > * major.minor: `libdb4.0`, `libdb4.1`
> > > > > * часть soname: `libcurl4`, `libflac8`
> > > > [...]
> > > > > * Если два пакета конфликтуют по путям, они не смогут сосуществовать — тогда
> > > > > старую версию нужно удалить, а все зависимости — пересобрать.
> > > > [...]
> > > > 
> > > > 
> > > > Здесь не очень понятно описано, что делать, если апстрим не задаёт
> > > > никакого soname для библиотеки. Ну то есть, очевидно, надо идти
> > > > в апстрим и заниматься просветительской работой, сопровождаемой
> > > > pull request'ами, но пока эта работа движется, библиотеку как-то
> > > > же можно запаковать.
> > > > 
> > > > Чаще всего такие библиотеки окажутся установлеными во что-то
> > > > похожее на %_libdir/libfoo.so. Переименоввывать её странно,
> > > > да и динамический компоновщик кажется не найдёт такую
> > > > библиотеку по какому-то другому имени. Значит, в разных
> > > > сборках такой библиотеки будет один и тот же файл. 
> > > > А это уже противоречит требованию предложенного policy.
> > > > 
> > > > На мой взгляд, разумнее всего такие библиотеки паковать
> > > > в пакет с именем libfoo и надеятся на лучшее, так как
> > > > пакет libfooN, набирающий со временем кофликты
> > > > с libfoo0, libfoo1, ..., libfoo$((N-1)) технически
> > > > ничем не лучше.
> > > > 
> > > > Можно конечно пытаться задать свой soname патчем. Это
> > > > решило бы многие проблемы, но есть опасность пересечься
> > > > со схемой формирования soname, которую рано или поздно
> > > > выберет апстрим.
> > > 
> > > Soname необходимо и достаточно менять - если произошло обратно
> > > несовместимое изменение ABI. Как правило, об этом изменении лучше всего
> > > знает только апстрим.
> > 
> > Это понятно, но не все апстримы одинаково квалифицированны.
> 
> То есть даже апстрим может не знать на 100%, что он поменял ABI (такие случаи
> бывают), что уж говорить о маинтайнере казуально следующем полиси.
> 
> > 
> > Собственно, всё моё письмо ставит вопрос -- а что делать, если
> > soname нет?
> 
> На уровне линкера вместо soname будет использоваться полное имя файла

Полное имя файла, если линковали полным именем. Если -lname, то будет
libname.so. А как именно линковали - как написал апстрим или угадал
cmake, например.

> -
> то есть логика изменения soname остается применима.
> 
> Тяжело будет правильно собрать пакет с клиентом для такой либы без
> unmet, особенно если .so в -devel и .so.X в lib-.
> 
> 
> > 
> > -- 
> >   wbr,
> >     iv m.
> > _______________________________________________
> > Devel mailing list
> > Devel@lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel