[devel] Добавленная проверка на duplicate module

[Vitaly Lipatov]

Dmitry V. Levin писал 8.11.20 1:47:
> On Sun, Nov 08, 2020 at 01:16:55AM +0300, Vitaly Lipatov wrote:
...
>> Те, кто пишет управление glusterfs через эту обвязку на python, берут 
>> и
>> пользуются. В общем случае, всё равно, какой из модулей будет 
>> подгружен.
>> При необходимости можно добавлять зависимость на конкретный пакет.
> 
> Насколько совместимы python3(gluster) от разных версий glusterfs, это
> отдельный вопрос.  Если они в чём-то несовместимы, это не стало бы
> неожиданностью.
Да, но эта несовместимость не имеет значения.

> 
> Проиллюстрирую примером из библиотек:
> $ apt-cache showpkg 'liblibreofficekitgtk.so()(64bit)'
> Package: liblibreofficekitgtk.so()(64bit)
..
> libreofficekit-still 6.4.7.2-alt1:sisyphus+260240.300.4.3 на 1603576136
> libreofficekit 7.0.1.2-alt2:sisyphus+259887.100.1.2 на 1602681375
> - два пакета провайдят одну библиотеку, которая никаким другим пакетам 
> не нужна.
..
> - и эти библиотеки, разумеется, несовместимы.
С библиотеками всё понятно. Опять же, пока нет критичных пользователей, 
несовместимость библиотек не имеет значения.

Можно посмотреть на такой же пример с libwine.so.1
и на пакет wine-grdwine
  $ rpm -q --requires wine-grdwine
libwine.so.1()(64bit) >= set:kikzKTTOo11
libwine.so.1(WINE_1.0)(64bit)

который ставится и работает с любой версией libwine.so.1 в некоторой 
широкой окрестности.

>> Так что, уже идти делать один python3-module-glusterfs из glusterfs8
>> последней версии?
> 
> Проблема не в том, что в репозитории две разные реализации
> python3(gluster), проблема в том, что они конкурируют за ABI.
Они конкурируют за ABI только для автоматически (не глядя) 
сформированных зависимостей. Разве это имеет значение? Для кого? Для 
несуществующего пользователя?

> В качестве простого решения я бы предложил оставить Provides
> этих интерфейсов только у одного из модулей.
А в policy что написать?

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