*** Bug 35976 has been marked as a duplicate of this bug. ***

Очень плохая проблема, когда мантейнеры не могут познакомиться, и в итоге в систему идут конфликтующие пакеты.

У меня есть предположение, что правильное название —
python-module-service_identity

https://pypi.org/project/service_identity/

(В ответ на комментарий №2)
> Очень плохая проблема, когда мантейнеры не могут познакомиться, и в итоге в
> систему идут конфликтующие пакеты.
> 

bugzilla -- отличное место для знакомства ;)

(In reply to comment #2)
> У меня есть предположение, что правильное название —
> python-module-service_identity

Я вешал на тот, который с '_', так как у него initial build позже, и значит именно его собирали зря. Зато с '_' c тех пор обновился, а с '-' нет.

220925 FAILED #1 sisyphus del=python-module-service_identity

       x86_64: NEW unmet dependencies detected:
matrix-synapse#0.34.1.1-alt1    python-module-service_identity >= 16.0.0
        i586: NEW unmet dependencies detected:
matrix-synapse#0.34.1.1-alt1    python-module-service_identity >= 16.0.0
        aarch64: NEW unmet dependencies detected:
matrix-synapse#0.34.1.1-alt1    python-module-service_identity >= 16.0.0
        ACLs of affected packages (1):
matrix-synapse  lav

Прошу прощения, что собрал конфликтующий пакет. Таск расшарен.

(В ответ на комментарий №5)
> 220925 FAILED #1 sisyphus del=python-module-service_identity
> 
>        x86_64: NEW unmet dependencies detected:
> matrix-synapse#0.34.1.1-alt1    python-module-service_identity >= 16.0.0
>         i586: NEW unmet dependencies detected:
> matrix-synapse#0.34.1.1-alt1    python-module-service_identity >= 16.0.0
>         aarch64: NEW unmet dependencies detected:
> matrix-synapse#0.34.1.1-alt1    python-module-service_identity >= 16.0.0
>         ACLs of affected packages (1):
> matrix-synapse  lav
> 
> Прошу прощения, что собрал конфликтующий пакет. Таск расшарен.

А почему мы в итоге удаляем service_identity? Ведь именно его название совпадает с названием модуля.
$ epm -ql python-module-ceph_volume
/usr/lib/python2.7/site-packages/ceph_volume/util/templates.py

Видимо, нужно склониться к какому-то записанному правилу наименования пакетов. Я всегда считал, что это python?-module-<название модуля>

(In reply to comment #6)

Извините, я по невнимательности дискусию пропустил. Исправляюсь.

> Видимо, нужно склониться к какому-то записанному правилу наименования пакетов.
> Я всегда считал, что это python?-module-<название модуля>

Может, я и не знаю чего, но это нигде не записано. Так я что обычно руководствуюсь принципом согласованности с наименованием пакетов - нижний регистр и дефисы в имени. Если нужно оригинальное имя модуля, то для этого есть provides/requires.

(In reply to comment #4)
> Я вешал на тот, который с '_', так как у него initial build позже, и значит
> именно его собирали зря. Зато с '_' c тех пор обновился, а с '-' нет.

C "-" обновлю, если, все-таки, решим его оставить.

(В ответ на комментарий №7)
> (In reply to comment #6)
> 
> Извините, я по невнимательности дискусию пропустил. Исправляюсь.
> 
> > Видимо, нужно склониться к какому-то записанному правилу наименования пакетов.
> > Я всегда считал, что это python?-module-<название модуля>
> 
> Может, я и не знаю чего, но это нигде не записано. Так я что обычно
> руководствуюсь принципом согласованности с наименованием пакетов - нижний
> регистр и дефисы в имени.
Что насчёт примера спека для модуля python:
https://www.altlinux.org/SampleSpecs/pythonmodule

А то ведь так можно и перловые модули к нижнему регистру привести.

И вот у меня установлены такие пакеты:
python-module-prompt_toolkit
python-module-lazy_object_proxy
python-module-OpenGL_accelerate
python-module-tornado_xstatic
python-module-mpl_toolkits
python-module-ipython_genutils
python3-module-sphinx_rtd_theme
python-module-jupyter_core
python-module-backports_abc
python-module-setuptools_scm
python-module-ceph_detect_init
python3-module-prometheus_client
python-module-jupyter_client
python-module-importlib_metadata
python3-module-importlib_metadata
python-module-scapy-ssl_tls
python-module-pygtk_git
python3-module-OpenGL_accelerate
python3-module-vk_api
python3-module-tornado_xstatic
python3-module-jupyter_client
python3-module-ninja_syntax
python3-module-pkg_resources
python-module-vk_api
python-module-backports.ssl_match_hostname
python-module-ceph_disk
python3-module-prompt_toolkit
python-module-requests_toolbelt
python-module-ceph_volume
python3-module-requests_toolbelt
python3-module-jupyter_core
python-module-pygtk_git-devel-data
python3-module-ipython_genutils
python-module-backports.functools_lru_cache
python-module-pkg_resources
python-module-argparse_tools
python-module-prometheus_client
python-module-service_identity
python-module-sphinx_rtd_theme
python3-module-mpl_toolkits

> Если нужно оригинальное имя модуля, то для этого есть
> provides/requires.

(In reply to comment #9)
> Что насчёт примера спека для модуля python:
> https://www.altlinux.org/SampleSpecs/pythonmodule

Пример - не полиси. И я пока не очень понимаю, в чем проблема именования с дефисом.  Вернее, понимаю, что rpmrb script автоматически генерирует зависимости, которые требуют жесткого правила именования - но это проблема rpmrb скрипта, предлагаю его и фиксить.

> А то ведь так можно и перловые модули к нижнему регистру привести.

Мы сейчас питоновские модули обсуждаем и у нас, насколько я знаю, для питоновских пакетов принято максимально полагаться на автомат и руками править места, где автомат не справился. К сожалению, rpmrb этого правила не придерживается. Взять, к примеру, ваш пакет matrix-synapse. Ему даже не нужен service_identity! Но rpmrb на автомате проставил эту мусорную зависимость.

По поводу того, что оставить - предлагаю оставить мой, так как он первый был и предоставляет пакет под Python 3.

(В ответ на комментарий №10)
> (In reply to comment #9)
> > Что насчёт примера спека для модуля python:
> > https://www.altlinux.org/SampleSpecs/pythonmodule
> 
> Пример - не полиси. И я пока не очень понимаю, в чем проблема именования с
> дефисом.
Видимо, тем, что это странная выдумка, которая мешает использованию %modulename
в названии пакета?

>  Вернее, понимаю, что rpmrb script автоматически генерирует
> зависимости, которые требуют жесткого правила именования - но это проблема
> rpmrb скрипта, предлагаю его и фиксить.
Нет, это не так.

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

> придерживается. Взять, к примеру, ваш пакет matrix-synapse. Ему даже не нужен
> service_identity! Но rpmrb на автомате проставил эту мусорную зависимость.
На всякий случай напишу, что rpmrb, как и другие скрипты этой серии, вообще не
об этом.

Пакету matrix-synapse напрямую действительно не нужен service_identity, но там
присутствует проверка версии этого модуля:
$ grep identity synapse/python_dependencies.py 
    "service_identity>=16.0.0",
Предполагаю, модуль используется опосредованно, через другой модуль, но важно,
чтобы он имел версию не ниже, что и гарантируется.

Я веду речь о том, что у нас недостаток в полиси, именование пакетов как
попало, конфликты пакетов из-за этого, а вы переводите тему на то, что некий
rpmrb плохо пакеты собирает. Если что, rpmrb — это я

(In reply to comment #12)

> Я веду речь о том, что у нас недостаток в полиси, именование пакетов как
> попало, конфликты пакетов из-за этого, а вы переводите тему на то, что некий
> rpmrb плохо пакеты собирает.

А баг вообще про то, что пакеты дублируются, и это стоит исправить.

Пакет с именим python-module-service-identity в Сизифе должен
всё равно осаться, как обычный или хотя бы как виртуальный,
хотя бы потому, что кто-то мог его и поставить -- он даже в p8
есть. Это же справедливо для python-module-service_identity,
хотя его в p8 нет.

Поэтому в пакете, который выживет, должны быть соответсвующие
provides/obsoletes на того, кто не выживет, и модуль для третьего
питона.

Так ли важно, что после этого попадёт в %{NAME}, а что в Provides?
По-моему, никакой разницы. Достаточно договориться, кто будет сопровождать
пакет дальше.

(In reply to comment #13)
> По-моему, никакой разницы. Достаточно договориться, кто будет сопровождать
> пакет дальше.

Я готов сопровождать дальше. Так что предлагаю
1. Текущий python-module-service_identity я удаляю
2. Свой обновляю до 18.1.0 и переименовываю в python-module-service_identity (оставив старое имя в Provides), так как мне именование не принципиально, а спорить ради спора смысла не вижу.

python-module-service-identity-18.1.0-alt1 -> sisyphus:

Fri Feb 15 2019 Vladimir Didenko <cow@altlinux> 18.1.0-alt1
- new version
- obsolete duplicate package (closes: #35296)