[devel] переработанный документ SharedLibsPolicy

[devel] переработанный документ SharedLibsPolicy

[Anton Farygin]

Всем привет.

Текущая версия документа |SharedLibsPolicy| в ALT Linux устарела как с 
точки зрения структуры, так и с точки зрения стиля подачи. Она написана 
сложным, перегруженным языком, что затрудняет понимание даже для опытных 
мейнтейнеров. В документе отсутствует чёткое разграничение между 
правилами, исключениями и примерами. Это приводит к неоднозначной 
трактовке, ошибкам в упаковке библиотек и затруднениям при сопровождении 
нескольких версий ABI.

Я предлагаю прочитать обновлённую версию данной политики, в которой я 
постарался сделать документ более читабельным и раскрыл некоторые 
тяжёлые для понимания моменты.

На мой взгляд я не забыл ничего из старого документа, если что-то 
заметите - напишите пожалуйста.

Текущая версия:
https://www.altlinux.org/Shared_Libs_Policy


Новая версия:


{{DraftPolicy
|responsible=PavlovKonstantin, AntonFarygin, IgorVlasenko
|metabug=repocop тесты library-pkgnames, lib-contains-devel-so
}}

== Shared Libs Policy ==

=== Определения ===

Разделяемая библиотека (shared library) — это файл с расширением .so, 
который предназначен для использования сразу несколькими программами.

Плагин — .so-файл, который загружается напрямую одним конкретным 
приложением (например, через dlopen). Такие файлы не попадают под это 
полиси.

=== Цель ===

Позволить библиотекам с разными несовместимыми ABI-версиями 
сосуществовать в системе. Это снижает риски поломок при обновлении, 
упрощает сопровождение и позволяет проводить обновления более гибко.

'''Кратко''':
''Нельзя класть новую библиотеку с новым soname в тот же бинарный пакет, 
где была старая.''

=== Библиотека (runtime часть) ===

* Каждая несовместимая версия библиотеки должна быть в отдельном 
бинарном пакете.
* Название пакета: `libfoo%abiversion`
* Если имя библиотеки заканчивается на цифру, то используется 
подчёркивание: `libfoo_%abiversion`
* В пакете не должно быть файлов с путями, не содержащими номер ABI.

Если есть общие файлы (напр., man-страницы, примеры), их нужно вынести в 
`libfoo-common`.
*Общий (-common) пакет должен быть только один — он используется всеми 
ABI-версиями библиотеки.
*-common пакет не должен включать файлы, которые зависят от ABI.
*Старый (Legacy) ABI-специфичный пакет не должен иметь жёсткой 
версионированной зависимости (Requires: с конкретной версией) от 
libfoo-common.

Пример: [https://packages.altlinux.org/sisyphus/srpms/libxmlb/specfiles/ 
libxmlb]

=== Имя исходного пакета ===

* Имя **исходного пакета (SRPM)** желательно сохранять таким же, как у 
апстрима — это упрощает отслеживание обновлений, использование 
автоматических инструментов (`repology.or`, `repocop`) и повышает 
предсказуемость.

* Однако, при обновлении библиотеки с '''ломкой ABI''', когда требуется 
сохранить в репозитории старую версию библиотеки:
   * исходный пакет со старой версией нужно **сохранять под отдельным 
именем** (например, `libfoo1`, `libfoo0`, `libfoo3.2`);
   * новый ABI собирается уже из SRPM с апстримным именем (`libfoo`), а 
старый SRPM остаётся в репозитории под переименованным именем.

* Таким образом, в репозитории могут одновременно присутствовать 
несколько SRPM, каждый из которых собирает свою версию ABI:
   - `libfoo` → собирает `libfoo2`, `libfoo-devel`, ...
   - `libfoo1` → собирает `libfoo1`

* Для бэкпортов:
   * имя SRPM должно соответствовать новому ABI;
   * старые SRPM не модифицируются;
   * оба SRPM должны собирать бинарные пакеты, которые могут быть 
установлены параллельно (если это возможно).

* Как только в репозитории **не останется ни одного пакета**, 
использующего старую версию ABI:
   * соответствующий SRPM (и его бинарные пакеты) должен быть **удалён**;
   * это уменьшает нагрузку на инфраструктуру и снижает риски путаницы;
   * наличие библиотеки в `System/Legacy libraries` не освобождает от 
этого требования — она должна быть удалена, если не используется ни 
одним другим пакетом.

* Для автоматизации отслеживания можно использовать:
   * `apt-cache rdepends libfoo1`
   * скрипты из `repocop` и `srpm-uploader`
   * веб-интерфейса [https://packages.altlinux.org 
packages.altlinux.org] → вкладка пакета '''Аналитика''' → '''Зависящие 
пакеты'''

=== development-файлы ===

* Заголовочные файлы и `.so`-файл без версии (используемый для линковки) 
должны быть вынесены в отдельный `-devel` пакет.

* По умолчанию `-devel` пакет должен быть только **один** — и он должен 
относиться к самой новой версии библиотеки:
   - `libfoo-devel`
   - или, если есть несколько версий ABI в системе: 
`libfoo%abiversion-devel`

* Поддержка нескольких `-devel` пакетов (например, `libfoo1-devel` и 
`libfoo2-devel`) допускается **только в исключительных случаях**, когда:
   - большое количество клиентов ещё не может быть пересобрано под новую 
библиотеку;
   - либо API существенно отличается, и одновременная поддержка 
действительно необходима.

* В случае одновременного существования нескольких `-devel` пакетов, они 
должны иметь явные `Conflicts:` друг с другом, чтобы исключить их 
совместную установку.

Для `.a` файлов:

* Если вместе с `.so`: `libfoo-devel-static` или 
`libfoo%abiversion-devel-static`
* Если только `.a`: просто `libfoo-devel`

Файлы, не предназначенные для линковки, а работающие как плагины 
(`dlopen`), не попадают под полиси. Пример: `libtcnative-1.so` из 
`tomcat-native`.

Об исключениях стоит сообщать в багзиллу: 
`altlinux-policy-shared-lib-contains-devel-so`

=== Пример упаковки разных ABI ===

Пакет с разными версиями ABI должен содержать только одну из них. Если 
библиотека имеет несколько .so с разными ABI — каждую версию упаковывают 
в отдельный пакет.

Пример: [https://packages.altlinux.org/sisyphus/srpms/ffmpeg/ ffmpeg]

== Как выбирать %abiversion ==

Если библиотека использует `soversion` — используем его как %abiversion.

Если `soversion` отсутствует или нестабилен — используем:

* возрастающее число: `libfoo0`, `libfoo1`
* major-версию: `libqt3`, `libqt4`
* major.minor: `libdb4.0`, `libdb4.1`
* часть soname: `libcurl4`, `libflac8`

== Что делать при ломке ABI ==

Допустим, soname изменился с N на M:

# Переименовать бинарный пакет `libfoo` → `libfooM` (или `libfooN` → 
`libfooM`)
# Проверить совместимость при установке:
   hsh-install libfoo libfooM

== Поддержка клиентов библиотеки ==

Рекомендуется иметь только один `-devel` пакет — для самой новой версии.

Если новая версия несовместима и вызывает ошибки сборки у многих пакетов 
— допустимо иметь 2 `-devel` пакета с `Conflicts` друг на друга. 
Зависимые пакеты разделяются по версии сборки.

Для `libfooM-devel` желательно прописывать:
   Provides: libfoo-devel = %EVR

== Старые версии библиотек ==

* Старые библиотеки помещаются в группу `System/Legacy libraries`.
* Они удаляются, если не используются другими пакетами.
* Такие пакеты не проходят в [[Branches|стабильные ветки]].

== Возможные проблемы ==

* Если два пакета конфликтуют по путям, они не смогут сосуществовать — 
тогда старую версию нужно удалить, а все зависимости — пересобрать.
* Проблемы apt при переименовании пакетов: 
[http://lists.altlinux.org/pipermail/devel/2009-May/171113.html пример]
* В одной программе могут оказаться разные версии одной библиотеки через 
цепочку зависимостей (libX → libZ1, libY → libZ2) — возможны трудные для 
отладки ошибки.

== Ссылки ==
* [[Shared Libs Policy Comments|Комментарий к Shared Libs Policy с 
пошаговой инструкцией]]
* [https://www.debian.org/doc/debian-policy/ch-sharedlibs.html 
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html]
* [[API or ABI changing|Смена API/ABI]]
* [[Shared Libs Policy and updates|Данное полиси и обновления]]
* [[Shared Library Symbol Versioning HOWTO]]

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

[Dmitry V. Levin]

On Thu, Aug 07, 2025 at 02:46:04PM +0300, Anton Farygin wrote:
> Всем привет.
> 
> Текущая версия документа |SharedLibsPolicy| в ALT Linux устарела как с 
> точки зрения структуры, так и с точки зрения стиля подачи. Она написана 
> сложным, перегруженным языком, что затрудняет понимание даже для опытных 
> мейнтейнеров. В документе отсутствует чёткое разграничение между 
> правилами, исключениями и примерами. Это приводит к неоднозначной 
> трактовке, ошибкам в упаковке библиотек и затруднениям при сопровождении 
> нескольких версий ABI.
> 
> Я предлагаю прочитать обновлённую версию данной политики, в которой я 
> постарался сделать документ более читабельным и раскрыл некоторые 
> тяжёлые для понимания моменты.
> 
> На мой взгляд я не забыл ничего из старого документа, если что-то 
> заметите - напишите пожалуйста.
> 
> Текущая версия:
> https://www.altlinux.org/Shared_Libs_Policy
> 
> 
> Новая версия:
> 
> 
> {{DraftPolicy
> |responsible=PavlovKonstantin, AntonFarygin, IgorVlasenko
> |metabug=repocop тесты library-pkgnames, lib-contains-devel-so
> }}
> 
> == Shared Libs Policy ==
> 
> === Определения ===
> 
> Разделяемая библиотека (shared library) — это файл с расширением .so, 
> который предназначен для использования сразу несколькими программами.

Что с этим определением не так?
- формулировка "файл с расширением .so" не подходит к GNU/Linux;
  наверное, автор имел в виду, что имя файла заканчивается на .so,
  но почему он это имел в виду, непонятно, ведь
- в GNU/Linux таких разделяемых библиотек, имена которых заканчиваются
  на .so, мало; dynamic linker загружает большую часть разделяемых
  библиотек по именам, которые не заканчиваются на .so;
- в GNU/Linux большинство файлов, имена которых заканчиваются на .so,
  используются не для загрузки dynamic linker'ом.

Лучше обойтись совсем без определений, чем с такими определениями.

Если весь этот черновик написан с таким пренебрежением к деталям,
то неудивительно, что он до сих пор черновик.


-- 
ldv

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

[Anton Farygin]

On 8/7/25 15:57, Dmitry V. Levin wrote:
> On Thu, Aug 07, 2025 at 02:46:04PM +0300, Anton Farygin wrote:
>> Всем привет.
>>
>> Текущая версия документа |SharedLibsPolicy| в ALT Linux устарела как с
>> точки зрения структуры, так и с точки зрения стиля подачи. Она написана
>> сложным, перегруженным языком, что затрудняет понимание даже для опытных
>> мейнтейнеров. В документе отсутствует чёткое разграничение между
>> правилами, исключениями и примерами. Это приводит к неоднозначной
>> трактовке, ошибкам в упаковке библиотек и затруднениям при сопровождении
>> нескольких версий ABI.
>>
>> Я предлагаю прочитать обновлённую версию данной политики, в которой я
>> постарался сделать документ более читабельным и раскрыл некоторые
>> тяжёлые для понимания моменты.
>>
>> На мой взгляд я не забыл ничего из старого документа, если что-то
>> заметите - напишите пожалуйста.
>>
>> Текущая версия:
>> https://www.altlinux.org/Shared_Libs_Policy
>>
>>
>> Новая версия:
>>
>>
>> {{DraftPolicy
>> |responsible=PavlovKonstantin, AntonFarygin, IgorVlasenko
>> |metabug=repocop тесты library-pkgnames, lib-contains-devel-so
>> }}
>>
>> == Shared Libs Policy ==
>>
>> === Определения ===
>>
>> Разделяемая библиотека (shared library) — это файл с расширением .so,
>> который предназначен для использования сразу несколькими программами.
> Что с этим определением не так?
> - формулировка "файл с расширением .so" не подходит к GNU/Linux;
>    наверное, автор имел в виду, что имя файла заканчивается на .so,
>    но почему он это имел в виду, непонятно, ведь
> - в GNU/Linux таких разделяемых библиотек, имена которых заканчиваются
>    на .so, мало; dynamic linker загружает большую часть разделяемых
>    библиотек по именам, которые не заканчиваются на .so;
> - в GNU/Linux большинство файлов, имена которых заканчиваются на .so,
>    используются не для загрузки dynamic linker'ом.
>
> Лучше обойтись совсем без определений, чем с такими определениями.
>
> Если весь этот черновик написан с таким пренебрежением к деталям,
> то неудивительно, что он до сих пор черновик.

Лучше дать корректное определение, конечно.

*Shared library в Linux* — это ELF-файл с расширением |.so.X[.Y.Z]|, 
содержащий исполняемый код, который загружается динамически во время 
выполнения программ.

Так лучше ?

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

[Vitaly Chikunov]

Dmitry,

On Thu, Aug 07, 2025 at 03:57:54PM +0300, Dmitry V. Levin wrote:
> On Thu, Aug 07, 2025 at 02:46:04PM +0300, Anton Farygin wrote:
> > Всем привет.
> > 
> > Текущая версия документа |SharedLibsPolicy| в ALT Linux устарела как с 
> > точки зрения структуры, так и с точки зрения стиля подачи. Она написана 
> > сложным, перегруженным языком, что затрудняет понимание даже для опытных 
> > мейнтейнеров. В документе отсутствует чёткое разграничение между 
> > правилами, исключениями и примерами. Это приводит к неоднозначной 
> > трактовке, ошибкам в упаковке библиотек и затруднениям при сопровождении 
> > нескольких версий ABI.
> > 
> > Я предлагаю прочитать обновлённую версию данной политики, в которой я 
> > постарался сделать документ более читабельным и раскрыл некоторые 
> > тяжёлые для понимания моменты.
> > 
> > На мой взгляд я не забыл ничего из старого документа, если что-то 
> > заметите - напишите пожалуйста.
> > 
> > Текущая версия:
> > https://www.altlinux.org/Shared_Libs_Policy
> > 
> > 
> > Новая версия:
> > 
> > 
> > {{DraftPolicy
> > |responsible=PavlovKonstantin, AntonFarygin, IgorVlasenko
> > |metabug=repocop тесты library-pkgnames, lib-contains-devel-so
> > }}
> > 
> > == Shared Libs Policy ==
> > 
> > === Определения ===
> > 
> > Разделяемая библиотека (shared library) — это файл с расширением .so, 
> > который предназначен для использования сразу несколькими программами.
> 
> Что с этим определением не так?
> - формулировка "файл с расширением .so" не подходит к GNU/Linux;
>   наверное, автор имел в виду, что имя файла заканчивается на .so,
>   но почему он это имел в виду, непонятно, ведь

Extension is usually defined as a suffix, not an ending, and suffixes
can be multiple.

> - в GNU/Linux таких разделяемых библиотек, имена которых заканчиваются
>   на .so, мало; dynamic linker загружает большую часть разделяемых
>   библиотек по именам, которые не заканчиваются на .so;
> - в GNU/Linux большинство файлов, имена которых заканчиваются на .so,
>   используются не для загрузки dynamic linker'ом.
> 
> Лучше обойтись совсем без определений, чем с такими определениями.
> 
> Если весь этот черновик написан с таким пренебрежением к деталям,
> то неудивительно, что он до сих пор черновик.
> 
> 
> -- 
> ldv
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Anton Farygin]

С Димой поработали над документом, а именно вместо определений появился 
раздел область действия, детально описывающий применимость данной политики.


{{DraftPolicy
|responsible=PavlovKonstantin, AntonFarygin, IgorVlasenko
|metabug=repocop тесты library-pkgnames, lib-contains-devel-so
}}

== Shared Libs Policy ==

=== Цель ===

Позволить библиотекам с разными несовместимыми ABI-версиями 
сосуществовать в системе. Это снижает риски поломок при обновлении, 
упрощает сопровождение и позволяет проводить обновления более гибко.

'''Кратко''':
''Нельзя класть новую библиотеку с новым soname в тот же бинарный пакет, 
где была старая.''

=== Область действия ===

Данная политика распространяется на:

* '''Публичные разделяемые библиотеки''' — `.so.*`-файлы (например, 
`libfoo.so.1`, `libbar.so.2.3`, а также `libbaz-3.1.so`), 
устанавливаемые в стандартные пути для динамического линковщика и 
предназначенные для использования несколькими независимыми программами. 
Это определение включает в себя библиотеки с альтернативными схемами 
именования, в которых ABI-версия зашита непосредственно в имя файла 
(например, `libname-X.Y.so`);
* '''Пакеты разработки (`-devel`)''', содержащие файлы для компоновки 
(`libfoo.so`), заголовочные файлы (`.h`) и другие материалы, необходимые 
для сборки программ, использующих библиотеку;
* '''Общие (`-common`) пакеты''', включающие файлы, не зависящие от ABI, 
— такие как конфигурационные файлы, ресурсы (иконки, XML, PNG, словари и 
т.п.), базы данных, скрипты, справочные материалы.

Политика '''не распространяется''' на:

* `.so`-файлы, загружаемые конкретным приложением как плагины (например, 
через `dlopen`);
* статические библиотеки (`.a`), если они используются отдельно и не 
влияют на ABI-совместимость;
* библиотеки, являющиеся частью одного монолитного пакета и не 
предназначенные для переиспользования другими программами (например, 
`libinternal.so`, установленная в нестандартный путь и используемая 
только одним приложением);
* библиотеки, собранные как часть одного приложения, устанавливаемые в 
стандартный путь (например, `/usr/lib64`), но не предназначенные для 
использования другими программами и не имеющие `-devel` пакета 
(например, `libmyappsupport.so.0`, используемая исключительно `myapp`).

'''Примеры:'''
* Под действие политики попадает `libfoo.so.1`, установленный в 
`/usr/lib64/`, используемый несколькими приложениями.
* Под действие политики также попадает `libfoo-devel`, содержащий 
`libfoo.so` и заголовки.
* Под действие политики также попадает `libfoo-common`, если в нём 
находятся ресурсы, применимые ко всем версиям ABI.
* Под действие политики также попадает `libbaz-3.1.so`, если она 
используется как разделяемая библиотека.
* Не попадает `libplugin_mytask.so`, загружаемый только одним 
приложением как модуль (plugin).
* Не попадает `libinternal.so`, устанавливаемый в `/opt/myapp/lib/` и 
используемый исключительно программой `myapp`.
* Не попадает `libmyappsupport.so.0`, установленный в `/usr/lib64`, но 
используемый только приложением `myapp`, если отсутствует 
`libmyappsupport-devel`.

Дополнительную информацию о принципах работы разделяемых библиотек в 
GNU/Linux-среде можно найти в [Program Library 
HOWTO](https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html).

=== Упаковка библиотек (runtime часть) ===

* Каждая несовместимая версия библиотеки должна быть в отдельном 
бинарном пакете.
* Название пакета: `libfoo%abiversion`
* Если имя библиотеки заканчивается на цифру, то используется 
подчёркивание: `libfoo_%abiversion`
* В пакете не должно быть файлов с путями, не содержащими номер ABI.

Если есть общие файлы (напр., man-страницы, примеры), их нужно вынести в 
`libfoo-common`.
*Общий (-common) пакет должен быть только один — он используется всеми 
ABI-версиями библиотеки.
*-common пакет не должен включать файлы, которые зависят от ABI.
*Старый (Legacy) ABI-специфичный пакет не должен иметь жёсткой 
версионированной зависимости (Requires: с конкретной версией) от 
libfoo-common.

Пример: [https://packages.altlinux.org/sisyphus/srpms/libxmlb/specfiles/ 
libxmlb]

=== Имя исходного пакета ===

* Имя **исходного пакета (SRPM)** желательно сохранять таким же, как у 
апстрима — это упрощает отслеживание обновлений, использование 
автоматических инструментов (`repology.or`, `repocop`) и повышает 
предсказуемость.

* Однако, при обновлении библиотеки с '''ломкой ABI''', когда требуется 
сохранить в репозитории старую версию библиотеки:
   * исходный пакет со старой версией нужно **сохранять под отдельным 
именем** (например, `libfoo1`, `libfoo0`, `libfoo3.2`);
   * новый ABI собирается уже из SRPM с апстримным именем (`libfoo`), а 
старый SRPM остаётся в репозитории под переименованным именем.

* Таким образом, в репозитории могут одновременно присутствовать 
несколько SRPM, каждый из которых собирает свою версию ABI:
   - `libfoo` → собирает `libfoo2`, `libfoo-devel`, ...
   - `libfoo1` → собирает `libfoo1`

* Для бэкпортов:
   * имя SRPM должно соответствовать новому ABI;
   * старые SRPM не модифицируются;
   * оба SRPM должны собирать бинарные пакеты, которые могут быть 
установлены параллельно (если это возможно).

* Как только в репозитории **не останется ни одного пакета**, 
использующего старую версию ABI:
   * соответствующий SRPM (и его бинарные пакеты) должен быть **удалён**;
   * это уменьшает нагрузку на инфраструктуру и снижает риски путаницы;
   * наличие библиотеки в `System/Legacy libraries` не освобождает от 
этого требования — она должна быть удалена, если не используется ни 
одним другим пакетом.

* Для автоматизации отслеживания можно использовать:
   * `apt-cache rdepends libfoo1`
   * скрипты из `repocop` и `srpm-uploader`
   * веб-интерфейса [https://packages.altlinux.org 
packages.altlinux.org] → вкладка пакета '''Аналитика''' → '''Зависящие 
пакеты'''

=== development-файлы ===

* Заголовочные файлы и `.so`-файл без версии (используемый для линковки) 
должны быть вынесены в отдельный `-devel` пакет.

* По умолчанию `-devel` пакет должен быть только **один** — и он должен 
относиться к самой новой версии библиотеки:
   - `libfoo-devel`
   - или, если есть несколько версий ABI в системе: 
`libfoo%abiversion-devel`

* Поддержка нескольких `-devel` пакетов (например, `libfoo1-devel` и 
`libfoo2-devel`) допускается **только в исключительных случаях**, когда:
   - большое количество клиентов ещё не может быть пересобрано под новую 
библиотеку;
   - либо API существенно отличается, и одновременная поддержка 
действительно необходима.

* В случае одновременного существования нескольких `-devel` пакетов, они 
должны иметь явные `Conflicts:` друг с другом, чтобы исключить их 
совместную установку.

Для `.a` файлов:

* Если вместе с `.so`: `libfoo-devel-static` или 
`libfoo%abiversion-devel-static`
* Если только `.a`: просто `libfoo-devel`

Файлы, не предназначенные для линковки, а работающие как плагины 
(`dlopen`), не попадают под полиси. Пример: `libtcnative-1.so` из 
`tomcat-native`.

Об исключениях стоит сообщать в багзиллу: 
`altlinux-policy-shared-lib-contains-devel-so`

=== Пример упаковки разных ABI ===

Пакет с разными версиями ABI должен содержать только одну из них. Если 
библиотека имеет несколько .so с разными ABI — каждую версию упаковывают 
в отдельный пакет.

Пример: [https://packages.altlinux.org/sisyphus/srpms/ffmpeg/ ffmpeg]

== Как выбирать %abiversion ==

Если библиотека использует `soversion` — используем его как %abiversion.

Если `soversion` отсутствует или нестабилен — используем:

* возрастающее число: `libfoo0`, `libfoo1`
* major-версию: `libqt3`, `libqt4`
* major.minor: `libdb4.0`, `libdb4.1`
* часть soname: `libcurl4`, `libflac8`

== Что делать при ломке ABI ==

Допустим, soname изменился с N на M:

# Переименовать бинарный пакет `libfoo` → `libfooM` (или `libfooN` → 
`libfooM`)
# Проверить совместимость при установке:
   hsh-install libfoo libfooM

== Поддержка клиентов библиотеки ==

Рекомендуется иметь только один `-devel` пакет — для самой новой версии.

Если новая версия несовместима и вызывает ошибки сборки у многих пакетов 
— допустимо иметь 2 `-devel` пакета с `Conflicts` друг на друга. 
Зависимые пакеты разделяются по версии сборки.

Для `libfooM-devel` желательно прописывать:
   Provides: libfoo-devel = %EVR

== Старые версии библиотек ==

* Старые библиотеки помещаются в группу `System/Legacy libraries`.
* Они удаляются, если не используются другими пакетами.
* Такие пакеты не проходят в [[Branches|стабильные ветки]].

== Возможные проблемы ==

* Если два пакета конфликтуют по путям, они не смогут сосуществовать — 
тогда старую версию нужно удалить, а все зависимости — пересобрать.
* Проблемы apt при переименовании пакетов: 
[http://lists.altlinux.org/pipermail/devel/2009-May/171113.html пример]
* В одной программе могут оказаться разные версии одной библиотеки через 
цепочку зависимостей (libX → libZ1, libY → libZ2) — возможны трудные для 
отладки ошибки.

== Ссылки ==
* [[Shared Libs Policy Comments|Комментарий к Shared Libs Policy с 
пошаговой инструкцией]]
* [https://www.debian.org/doc/debian-policy/ch-sharedlibs.html 
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html]
* [[API or ABI changing|Смена API/ABI]]
* [[Shared Libs Policy and updates|Данное полиси и обновления]]
* [[Shared Library Symbol Versioning HOWTO]]

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

[Anton Farygin]

On 8/8/25 00:16, ??????? ???????? wrote:
> Неплохо было бы, наверное, сразу определить исключения и почему они есть.

Там же определено в первом разделе "Область действия":

Политика '''не распространяется''' на:

* `.so`-файлы, загружаемые конкретным приложением как плагины (например, 
через `dlopen`);
* статические библиотеки (`.a`), если они используются отдельно и не 
влияют на ABI-совместимость;
* библиотеки, являющиеся частью одного монолитного пакета и не 
предназначенные для переиспользования другими программами (например, 
`libinternal.so`, установленная в нестандартный путь и используемая 
только одним приложением);
* библиотеки, собранные как часть одного приложения, устанавливаемые в 
стандартный путь (например, `/usr/lib64`), но не предназначенные для 
использования другими программами и не имеющие `-devel` пакета 
(например, `libmyappsupport.so.0`, используемая исключительно `myapp`).


если есть ещё чем дополнить - помогайте.

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

[Ivan A. Melnikov]

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

В общем, я не могу ничего рекомендовать для такой ситуации,
однако мне кажется SharedLibsPolicy должна явно описать
случай отсутствия soname.

-- 
  wbr,
    iv m.

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

[Vitaly Chikunov]

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.
> 
> Странная формулировка.

Более того, это бесполезное требование так как у нас зависимости на soname.

> 
> [...]
> > == Как выбирать %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, которую рано или поздно
> выберет апстрим.
> 
> В общем, я не могу ничего рекомендовать для такой ситуации,
> однако мне кажется SharedLibsPolicy должна явно описать
> случай отсутствия soname.
> 
> -- 
>   wbr,
>     iv m.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Vitaly Chikunov]

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. Как правило, об этом изменении лучше всего
знает только апстрим.

> 
> В общем, я не могу ничего рекомендовать для такой ситуации,
> однако мне кажется SharedLibsPolicy должна явно описать
> случай отсутствия soname.
> 
> -- 
>   wbr,
>     iv m.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Ivan A. Melnikov]

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. Как правило, об этом изменении лучше всего
> знает только апстрим.

Это понятно, но не все апстримы одинаково квалифицированны.

Собственно, всё моё письмо ставит вопрос -- а что делать, если
soname нет?

-- 
  wbr,
    iv m.

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

[Anton Midyukov]

15.08.2025 09:35, Ivan A. Melnikov пишет:
> 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. Как правило, об этом изменении лучше всего
>> знает только апстрим.
> 
> Это понятно, но не все апстримы одинаково квалифицированны.
> 
> Собственно, всё моё письмо ставит вопрос -- а что делать, если
> soname нет?
> 

Прятать в подкаталог?

-- 
best regards, Anton Midyukov <antohami@altlinux.org>

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

[Vitaly Chikunov]

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

Тяжело будет правильно собрать пакет с клиентом для такой либы без
unmet, особенно если .so в -devel и .so.X в lib-.


> 
> -- 
>   wbr,
>     iv m.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Vitaly Chikunov]

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