Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#62687 - [python-perf] package name conflict: need rename to python-pyperf

Attached to Project: Community Packages
Opened by Daurnimator (daurnimator) - Tuesday, 21 May 2019, 04:24 GMT
Last edited by Balló György (City-busz) - Friday, 30 August 2019, 04:53 GMT
Task Type Bug Report
Category Packages
Status Assigned
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No


'perf' is the name of the python bindings to the linux 'perf' utility.

The upstream of this current python-perf package has resolved the naming conflict by renaming their project ( to 'pyperf'.

We should rename this package to make room for the linux perf tool bindings.
This task depends upon

This task blocks these from closing
FS#62697 - [linux-tools] python bindings not installed
Comment by Daurnimator (daurnimator) - Tuesday, 21 May 2019, 04:35 GMT
An easy way out might be to drop this package; it's currently an orphan and only used as a checkdepends.

EDIT: I misread, it's not an orphan
Comment by Levente Polyak (anthraxx) - Wednesday, 22 May 2019, 13:27 GMT
right now that commit helps nothing as pyperf is already taken on pypi and upstream needs to do something.
we gonna wait until its solved properly and there is a way out, dropping is not an option its a widely used toolset to profile python.
Comment by Sébastien Luttringer (seblu) - Monday, 12 April 2021, 17:01 GMT
Levente, what do you want we do about this naming issue?
Comment by Levente Polyak (anthraxx) - Monday, 12 April 2021, 19:20 GMT
@seblu: things seem to have sorted out upstream in the meanwhile. vstinner repo has been integrated into 'psf' which is the pyperf module holder in pypi. yippie.
ld;dr: gonna rename the package during this week and free up "python-perf", but we will need some "migration persion" which holds a replaces=() for some while to allow transparent migration path. If we dont want this, we need some news entry as people will end up with different packages for python-perf suddenly.
Comment by Sébastien Luttringer (seblu) - Tuesday, 13 April 2021, 09:50 GMT
I prefer solutions which allow users to upgrade their arch system across long time period.

I see PKGBUILD replaces=() support versions, so what do you think of adding something like replaces=(python-perf<=1.6-5) in the new package. There no need for migration wait period, this could work as soon as the new package is released (and be kept forever).
Linux-tools base package is in version 5.11, so versioning is higher and the first release will be >1.6-5.