У нас таких пакетов много. Предпочтительнее делать conflicts-obsoletes.

(Ответ для Grigory Ustinov на комментарий #1)
> У нас таких пакетов много. Предпочтительнее делать conflicts-obsoletes.

А obsoletes разве недостаточно? Нужен ещё и conflicts?

На каком основании указываете Obsoletes? Модули python3 ни разу не obsolete для python. Мне кажется корректно указывать только конфликт.

(Ответ для Alexey Shabalin на комментарий #3)
> На каком основании указываете Obsoletes? Модули python3 ни разу не obsolete
> для python. Мне кажется корректно указывать только конфликт.
В ряде случаев, когда python2-пакет содержал команду, разумно заместить эту команду командой из пакета python3.

> либо переименовать файлы в %_bindir/, заменив окончание .py на .py3
Обычно в bindir кладут файлы без расширения, поэтому я бы всячески боролся с .py3. Если кому-то очень надо, можно .py2 сделать.

(Ответ для Vitaly Lipatov на комментарий #4)
> (Ответ для Alexey Shabalin на комментарий #3)
> > На каком основании указываете Obsoletes? Модули python3 ни разу не obsolete
> > для python. Мне кажется корректно указывать только конфликт.
> В ряде случаев, когда python2-пакет содержал команду, разумно заместить эту
> команду командой из пакета python3.
> 

Я придираюсь, но "разумность" тут не то определение :) Удобство, замести мусор под ковер, или что-то аналогичное, но не разумность :)

Представьте, что в каком-то пакете (программе на python2) вручную выставлена зависимость на python-module-foo,которая автоматом не вычисляется (autoreq для python2 не идеален), если вместо него прилетит по зависимости python3-module-foo, то получим нерабочую программу.
Так что для одинаковых бинарников (скриптов в /usr/bin)  будет более честно выставить конфликт.

(Ответ для Alexey Shabalin на комментарий #5)
> (Ответ для Vitaly Lipatov на комментарий #4)
> > (Ответ для Alexey Shabalin на комментарий #3)
> > > На каком основании указываете Obsoletes? Модули python3 ни разу не obsolete
> > > для python. Мне кажется корректно указывать только конфликт.
> > В ряде случаев, когда python2-пакет содержал команду, разумно заместить эту
> > команду командой из пакета python3.
> > 
> 
> Я придираюсь, но "разумность" тут не то определение :) Удобство, замести
> мусор под ковер, или что-то аналогичное, но не разумность :)
> 
> Представьте, что в каком-то пакете (программе на python2) вручную выставлена
> зависимость на python-module-foo,которая автоматом не вычисляется (autoreq
> для python2 не идеален), если вместо него прилетит по зависимости
> python3-module-foo, то получим нерабочую программу.
> Так что для одинаковых бинарников (скриптов в /usr/bin)  будет более честно
> выставить конфликт.
Возможно, есть путаница с Provides.
Если пакет содержит переиспользуемые модули, Provides там быть не должно.
Но при Obsoletes пакет не прилетит вместо. Он удалит собой python-module-foo. И тот пакет, который его требовал, будет вынужден удалиться тоже.

То есть
Conflicts точно (поскольку есть пересечение по файлам).
Provides — нет
Obsoletes — если мы хотим предложить ту же команду, и заместить старый пакет.

Есть же ещё один вариант. Вынести %_bindir/ из пакета в отдельный пакет. И назначить конфликт ему. Это позволит одновременно использовать python3-module, не удаляя старый python-module.

Может стоит поставить вопрос о введении политики запрета упаковки %_bindir в python3-module? Раз модуль, то там должен быть только модуль.

(Ответ для Vitaly Lipatov на комментарий #4)
> Обычно в bindir кладут файлы без расширения, поэтому я бы всячески боролся с
> .py3. Если кому-то очень надо, можно .py2 сделать.

А как вариант с окончанием -py и -py3?

(Ответ для Антон Мидюков на комментарий #7)
> Есть же ещё один вариант. Вынести %_bindir/ из пакета в отдельный пакет. И
> назначить конфликт ему. Это позволит одновременно использовать
> python3-module, не удаляя старый python-module.
> 
> Может стоит поставить вопрос о введении политики запрета упаковки %_bindir в
> python3-module? Раз модуль, то там должен быть только модуль.
Хорошее предложение. И надо его совместить с запретом провайдить модули python, если пакет не python3-module. Чтобы разные серверы и программы не провайдили свои потроха, предназначенные для внутреннего использования. Лучше, конечно, не в публичный site-packages их ставить, но я не знаю, как.

> (Ответ для Vitaly Lipatov на комментарий #4)
> > Обычно в bindir кладут файлы без расширения, поэтому я бы всячески боролся с
> > .py3. Если кому-то очень надо, можно .py2 сделать.
> 
> А как вариант с окончанием -py и -py3?
Мне кажется, название команд нельзя менять, их же потом скрипты не найдут. Сейчас python2 в прошлом, и я бы перестал его учитывать. Другое дело, что скоро у нас в пакетах python3-modules- будут лежать модули для 4-го питона :)

python3-module-intelhex-2.2.1-alt3 -> sisyphus:

 Tue Oct 06 2020 Grigory Ustinov <grenka@altlinux> 2.2.1-alt3
 - Fix port on python3 (Closes: #39039).

(Ответ для Repository Robot на комментарий #9)
> python3-module-intelhex-2.2.1-alt3 -> sisyphus:
> 
>  Tue Oct 06 2020 Grigory Ustinov <grenka@altlinux> 2.2.1-alt3
>  - Fix port on python3 (Closes: #39039).

Договорились же не делать obsoletes?
http://git.altlinux.org/gears/p/python3-module-intelhex.git?p=python3-module-intelhex.git;a=commitdiff;h=c97b02b48f0d5531e8034837892e04423c918199

(Ответ для Антон Мидюков на комментарий #10)
> (Ответ для Repository Robot на комментарий #9)
> > python3-module-intelhex-2.2.1-alt3 -> sisyphus:
> > 
> >  Tue Oct 06 2020 Grigory Ustinov <grenka@altlinux> 2.2.1-alt3
> >  - Fix port on python3 (Closes: #39039).
> 
> Договорились же не делать obsoletes?
> http://git.altlinux.org/gears/p/python3-module-intelhex.git?p=python3-module-
> intelhex.git;a=commitdiff;h=c97b02b48f0d5531e8034837892e04423c918199

Кто договорился? Я делаю так, как делал с другими питоновскими модулями. Я ни с кем ни о чём договаривался.