В Сизифе этот же модуль уже собран как python-module-service-identity (https://packages.altlinux.org/en/Sisyphus/srpms/python-module-service-identity), который имеет чуть более давнюю историю и столь же свеж.
*** 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)
