Bug 53296

One of the possible options to handle this:

- add compat macro for setuptools-generated dist-info. It's either
  standard normalization (modern) or setuptools' one (legacy).
  The default can be switched depending on a branch (set by
  rpm-build-python3).
  - pros:
    - this allows to seamlessly copy packages between branches
  - cons:
    - need to maintain the macro and backport rpm-build-python3 to
      supported branches
    - need to take care of the default on setuptools backport

Я уже говорил, что макрос про dist-info совсем неудачный оказался и в своих пакетах я его использую только если если забываю убрать после автогенерации спека.

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

(In reply to Grigory Ustinov from comment #2)
> Я уже говорил, что макрос про dist-info совсем неудачный оказался и в своих
> пакетах я его использую только если если забываю убрать после автогенерации
> спека.

Имя директории *.dist-info стандартизировано и все сборочные бэкенды следуют
этому стандарту, все кроме setuptools < 75.8.1 (так исторически сложилось).
То есть имя сгенерированной директорий фактически собранного
проекта должно совпадать (читать как assert) с ожидаемым %pyproject_distinfo.

Сейчас в случае с setuptools и проектами, имя которых не нормализуется согласно стандарту, имя dist-info жестко прибито гвоздями или "просто" заглобленно с "*". Например,
https://git.altlinux.org/gears/p/python3-module-zope.testrunner.git?p=python3-module-zope.testrunner.git;a=blob;f=.gear/zope.testrunner.spec;h=9714735fac8efa8174c5277e49e470fffcb86b0b;hb=f5ed172e958bbb6f238a68f96ad2477fe2f55709#l64

> %define pypi_name zope.testrunner
> %python3_sitelibdir/%pypi_name-%version.dist-info/

С setuptools >= 75.8.1, это ожидание будет сломано, потому что имя dist-info будет нормализовано согласно стандарту. В примере с zope.testrunner
это zope_testrunner-7.0.dist-info (. заменено на _).

То есть проблема не в использовании %pyproject_distinfo, а проблема в отсутствии соответствующего макроса для setuptools и его неиспользовании, что и привело к ручному заданию ожиданий. Сейчас можно было бы переключить нормализацию на стандартный вариант и не пришлось бы править какую-то часть из 241 спеков. Но имеем, что имеем, теперь придется поправить эти спеки, вопрос как именно.

1) меняем *.dist-info на %pyproject_distinfo и забываем про
особенности setuptools ... пока такие пакеты не понадобится скопировать в
бранчи с setuptools < 75.8.1, бэкпорт которого реалистичен для p11 и потребует
значительных усилий для всего остального.

2) делаем макрос для совместимости между бранчами с возможностью переключения реализации (sisyphus - standard, p11 - setuptools, p10 - setuptools, etc.).
Меняем *.dist-info на %pyproject_distinfo_setuptools_compat (просто например!),
бэкпортим rpm-build-python3. Пакеты можно копировать. Это более сложный вариант.

(Ответ для Stanislav Levin на комментарий #3)
> С setuptools >= 75.8.1, это ожидание будет сломано, потому что имя dist-info
> будет нормализовано согласно стандарту. В примере с zope.testrunner
> это zope_testrunner-7.0.dist-info (. заменено на _).
> 
> То есть проблема не в использовании %pyproject_distinfo, а проблема в
> отсутствии соответствующего макроса для setuptools и его неиспользовании,
> что и привело к ручному заданию ожиданий. Сейчас можно было бы переключить
> нормализацию на стандартный вариант и не пришлось бы править какую-то часть
> из 241 спеков. Но имеем, что имеем, теперь придется поправить эти спеки,
> вопрос как именно.

Написать скрипт, который в автоматическом или полуавтоматическом режиме всё поправит. Если у вас на это не хватает квалификации, позвольте это сделать мне.