https://bugzilla.redhat.com/show_bug.cgi?id=2440297
--- Comment #7 from Ben Beasley <[email protected]> --- (In reply to Basil Crow from comment #5) > Thanks Ben for teaching me about the distinction between source and binary > package names. I am fine keeping the source package named rust-ptools, and > the binary package named ptools. "dnf install ptools" will work which is > what I care about. I want to use rust2rpm, so I don't want to package from > the GitHub source archives. > > I have updated to 0.2.11, which includes some new utilities and man pages > (now packaged as well). I also think I have fixed the test failure on s390x. > As stated in the README at https://github.com/basil/ptools I am deliberately > not trying to compete with popular tools like pgrep, pkill, pldd, and pwdx > which are part of many Fedora system already as part of procps-ng or glibc. > pflags is an outlier, being only distributed as part of python3-linux-procfs > and used by tuna and tuned. This doesn't seem as widely used, so I am fine > conflicting with it. I have added an explicit Conflicts: line to the package. Per https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_incompatible_binary_files_with_conflicting_naming_and_stubborn_upstreams, you’re supposed to try to work with both upstreams. Now, one upstream is the kernel, so I doubt renaming is on the table, and the other upstream appears to be you, and you’re reproducing a historical set of tools, so you can’t rename pflags and maintain “API” compatibility. If you’re going to add explicit Conflicts, though, we need to work with the maintainer of the other package to add it there as well, and I think we’re going to have to do some work to minimize the scope of the conflict. $ repoquery --whatrequires python3-linux-procfs Last metadata expiration check: 0:05:49 ago on Sat 21 Feb 2026 08:39:36 GMT. tuna-0:0.19-13.fc43.noarch tuned-0:2.26.0-2.fc43.noarch tuned-0:2.27.0-0.1.rc1.fc43.noarch Since tuned requires python3-linux-procfs, and tuned is the default power profile management daemon in at least Fedora Workstation and KDE Plasma, if your package conflicts with python3-linux-procfs then it won’t be installable on most Fedora installations. I think the right course of action will be to start a dialogue with the maintainers of the python-linux-procfs package in Fedora about what to do. Here are some possible suggestions: If nothing in Fedora uses the “pflags” executable from python3-linux-procfs, maybe we can just stop shipping it (beginning with F44 if the change is made before Final Freeze, or F45 otherwise, because removing a binary is a breaking change for stable releases). Then there will be no conflict. If nothing in Fedora uses the “pflags” executable from python3-linux-procfs but the maintainers still want to ship it, maybe they would consider renaming it downstream (python-pflags, maybe)? This should also be avoided in stable releases, but would fix the conflict going forward. If the maintainers of the python-linux-procfs don’t want to drop or rename the “pflags” executable, then you should ask them to at least move it to its own subpackage, maybe something like “python-linux-procfs-tools,” that depends on python3-linux-procfs. Then the Conflicts can be added to the subpackage containing the executable, greatly narrowing the scope of the problem, and thereby allowing your package to be parallel-installed with tuned. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2440297 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202440297%23c7 -- _______________________________________________ package-review mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
