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

[mikhailnov на altlinux.org]

08.11.2020 01:34, Vitaly Lipatov пишет:
> mikhailnov на altlinux.org писал 8.11.20 1:22:
>> 08.11.2020 01:16, Vitaly Lipatov пишет:
>>>> $ apt-cache showpkg 'python3(gluster)'
>>>> Package: python3(gluster)
>>>> Versions:
>>>>
>>>> Reverse Depends:
>>>> Dependencies:
>>>> Provides:
>>>> Reverse Provides:
>>>> python3-module-glusterfs8 8.2-alt2:sisyphus+259896.40.2.1 на 1602686473
>>>> python3-module-glusterfs7 7.8-alt1:sisyphus+259197.100.1.1 на 1601808930
>>>>
>>>> Да, в репозитории у этих модулей нет пользователей,
>>>> но как вы предлагаете этим пользоваться?
>>> Те, кто пишет управление glusterfs через эту обвязку на python, берут и пользуются. В общем случае, всё равно, какой из модулей будет подгружен. При необходимости можно добавлять зависимость на конкретный пакет.
>> Кому все равно? В python невозможно проконтролировать "ABI", если
>> мейнтейнер пакет Х проверял его работу с реализацией модуля А, откуда
>> он знает, как будет работать с реализацией Б? И как при обновлениях
>> потребителей этой реализации быть, если часть перестают быть с ней
>> совместимы?
> С высоты моего опыта использования этого python-модуля никакой разницы нет, и обновления беспроблемны.
> Если возникнет необходимость, тем более если будет пакет X, всегда можно вписать
> Requires: python3-module-glusterfs8
> И именно таким образом быть уверенным в требуемой версии.

Здесь у сборщика пакета, которому нужен python3-foo, встает выбор:

- либо абстрагироваться от имен пакетов, постоянной возни с питономодулями и не использовать конкретное имя проекта, используя python3(foo)

- либо прописать конкретное имя пакета

Мне первый подход кажется более правильным в масштабе репозитория, т.к. сопровождающие питономодулей должны сами поддерживать их в хорошем состоянии, но ситуации, когда провайд есть у нескольких пакетов, могут вынудить перейти на второй подход, вряд ли это хорошо.

>
> А если я запакую его как все пакеты, в python3-module-glusterfs, и буду менять с каждой мажорной версией glusterfs, то вот тогда у потребителей могут начаться неустранимые проблемы (опять же, можно привязаться к версии пакета, вот только альтернативы уже не будет).
>
>
>