New openmpi requires prrte. prrte itself provides /usr/bin/pterm, which conflicts with the same file in putty package. Reproducible: Always Steps to Reproduce: 1. try to update openmpi (requires prrte) Actual Results: file /usr/bin/pterm from install of prrte-3.0.2-1.fc40.x86_64 conflicts with file from package putty-0.79-1.fc40.x86_64 file /usr/share/man/man1/pterm.1.gz from install of prrte-3.0.2-1.fc40.x86_64 conflicts with file from package putty-0.79-1.fc40.x86_64 Expected Results: No conflicts. I understand, that it is too complex to find unique names for programs, but it must be some acceptable solution. Putty is not a critical package, but in some cases may be convenient, and I prefeer not to drop it.
It seems, that pterm from putty is an another terminal emulator, and not used often or automatically. This binary may be renamed or moved to separate subpackage.
I'm sorry, it's not clear to me what your proposed solution is.
I propose to rename pterm from putty package to pterm-putty or so on, as this pterm rarely used (i suppose).
Let's get the putty folks involved. But I'm leaning towards installing the prrte binaries into the MPI specific bin directories.
(In reply to Anton Guda from comment #1) > It seems, that pterm from putty is an another terminal emulator, and not > used often or automatically. > This binary may be renamed or moved to separate subpackage. Sorry, putty is in Fedora since f10 and is shipping the pterm for the whole time, e.g. fc11 from the year 2009 had it: https://koji.fedoraproject.org/koji/rpminfo?rpmID=1079379 On the other hand prrte is in Fedora since f36 thus it's apparent the package shouldn't get in in the state it is, because it couldn't pass the Fedora review and it's clearly prrte reviewer/packager fault. I really don't get why putty should rename if it's the prrte who caused the conflict. Reassigning to prrte.
I agree that we want to rename the file in prrte, rather than in putty, since putty is much older and more known. Prrte upstream has just decided to refuse a rename [1]. Archlinux renamed the file to prrte-pterm [2], and I suggest we do the same. [1] https://github.com/openpmix/prrte/issues/1836#issuecomment-1928480498 [2] https://gitlab.archlinux.org/archlinux/packaging/packages/prrte/-/merge_requests/1/diffs
Why not just move it into the MPI bin directory?
Because the user might have the other pterm and might be using it. Now if they enable the MPI module, they will get the new pterm in $PATH. One realistic example where this might happen: our builds of openssh have dropped support for some old SSH protocols and encryption algorithms, but some people still have old hardware that doesn't support the new stuff, and one of the commonly used workarounds is to use a second ssh client implementation, and putty is a popular choice. Putting the binary in a different path solves the immediate *packaging* problem, i.e. the files don't conflict during installation. But the bigger issue of having two binaries with the same is not resolved.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle. Changing version to 40.
OK, but could we please find some solution to this? I just had a dnf system-upgrade attempt from F39 to F40 error out on me three times, because I have putty installed in F39. The upgrade was attempting to install both putty and prrte for F40, and kept bashing into their conflict. (I don't know if prrte is pulled in by some other package, or if it's in the default install set for some reason. But it wasn't previously installed on my system, only putty.) The prrte package should never have passed review in the first place, if it was introducing file conflicts into the package collection, and it can't continue to sit there creating conflicts with a package that's been there for more than 10 years already. @zjedrzej If renaming or moving the prrte pterm might cause issues for the users who have both prrte and putty installed, I feel for them. But I feel far more for the MANY MORE users like myself, who have no interest whatsoever in prrte, but have it blocking their upgrades anyway due to the conflicts it creates. I had to uninstall putty in F39 to get the upgrade to finally go through, which absolutely should not have to be the solution to this. (And once F40 is installed, I'll have to uninstall prrte and reinstall putty.)
(I meant to add: And if we can't find a solution to this that everyone can agree on ASAP, then can someone at least push out a prrte update that explicitly marks it as "Conflicts: putty <= 0.82" for now, while it does? So that the conflict doesn't have to be discovered very late in the transaction test, when users attempt upgrades or installs that combine it with putty?)
Not a good solution. openmpi depends on prrte, and openmpi is really used by many useful packages. putty is a useful tool too. On the other hand, pterm from putty in not a critical part, so it can be moved to separate aux package (good), or renamed (not so good). I know nothing about pterm from prrte. Is it possible to rename or separate its pterm from main package? It was installed only as dependency.
My plan is to go with moving the binaries and man pages into the openmpi bin/man path. See https://src.fedoraproject.org/rpms/prrte/pull-request/4.
FEDORA-2024-b8d72bed9b (prrte-3.0.2-5.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-b8d72bed9b
FEDORA-2024-b8d72bed9b has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-b8d72bed9b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-b8d72bed9b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-b8d72bed9b (prrte-3.0.2-5.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.