Fedora Account System
Red Hat Associate
Red Hat Customer
Recent update of pcp-7.2.0-1.fc43 includes now package pcp-atop as dependency which conflicts with installed package atop during install: $ dnf upgrade pcp Package Arch Version Repository Size Upgrading: pcp x86_64 7.2.0-1.fc43 updates 4.5 MiB replacing pcp x86_64 7.1.5-3.fc43 updates 5.5 MiB pcp-conf x86_64 7.2.0-1.fc43 updates 224.9 KiB replacing pcp-conf x86_64 7.1.5-3.fc43 updates 80.8 KiB pcp-libs x86_64 7.2.0-1.fc43 updates 3.4 MiB replacing pcp-libs x86_64 7.1.5-3.fc43 updates 2.3 MiB pcp-selinux x86_64 7.2.0-1.fc43 updates 18.9 KiB replacing pcp-selinux x86_64 7.1.5-3.fc43 updates 18.8 KiB pcp-system-tools x86_64 7.2.0-1.fc43 updates 465.5 KiB replacing pcp-system-tools x86_64 7.1.5-3.fc43 updates 1.1 MiB python3-pcp x86_64 7.2.0-1.fc43 updates 390.5 KiB replacing python3-pcp x86_64 7.1.5-3.fc43 updates 381.9 KiB Installing dependencies: pcp-atop x86_64 7.2.0-1.fc43 updates 387.7 KiB pcp-dstat x86_64 7.2.0-1.fc43 updates 165.7 KiB pcp-htop x86_64 7.2.0-1.fc43 updates 335.8 KiB pcp-selinux-import x86_64 7.2.0-1.fc43 updates 12.3 KiB [...] Running transaction Transaction failed: Rpm transaction failed. - file /etc/sysconfig/atop from install of pcp-atop-7.2.0-1.fc43.x86_64 conflicts with file from package atop-2.12.1-1.fc43.x86_64 - file /usr/bin/atop from install of pcp-atop-7.2.0-1.fc43.x86_64 conflicts with file from package atop-2.12.1-1.fc43.x86_64 - file /usr/bin/atopsar from install of pcp-atop-7.2.0-1.fc43.x86_64 conflicts with file from package atop-2.12.1-1.fc43.x86_64 - file /usr/lib/systemd/system/atop.service from install of pcp-atop-7.2.0-1.fc43.x86_64 conflicts with file from package atop-2.12.1-1.fc43.x86_64 - file /usr/share/man/man1/atop.1.gz from install of pcp-atop-7.2.0-1.fc43.x86_64 conflicts with file from package atop-2.12.1-1.fc43.x86_64 - file /usr/share/man/man1/atopsar.1.gz from install of pcp-atop-7.2.0-1.fc43.x86_64 conflicts with file from package atop-2.12.1-1.fc43.x86_64 Reproducible: Always Additional Information: pcp installed: pcp-7.1.5-3.fc43.x86_64 Upgrade to pcp-7.2.0-1.fc43.x86_64 atop installed: atop-2.12.1-1.fc43.x86_64
This is expected behaviour, pcp-atop and atop now provide equivalent functionality (and many files with the same names) and cannot co-exist - you are required to choose one or the other. Its also pcp-system-tools that depends on pcp-atop FWIW, not pcp itself (pcp-system-tools depends on a matching pcp version, so it would have been forced upgrade as a result of your pcp upgrade here.
It's okay if you have to choose one of the two packages. However, when updating, the resulting new conflict should be displayed during the dependency check, not only when the conflicting files are to be installed.
Yes, good point - I'll look into improving this for the next release update. Thanks!
I am sorry, but I disagree. Requiring manual intervention to update your system should not be ok. I had atop installed. If you require pcp-atop as a true dependecy (not a weak one), even if I did not request pcp-atop, it should replace the installed atop package and not throw a conflict and abend. See also https://discussion.fedoraproject.org/t/198482
Hmm, that's an interesting perspective. An upgrade rather than a conflict is indeed another option. Our goals with adding this sub-package were twofold (previously pcp-atop was in pcp-system-tools FWIW): - the capabilities of pcp-atop(1) advanced such that it's now a drop-in replacement for atop (i.e. its a standalone tool, doesn't require any other services like pmcd / pmlogger anymore, including its own systemd setup for recording data in /var/log/atop, and so on). This warrants visibility at the packaging level, to make people aware, and to give more choice in opting-out - there are pcp installations where this package isn't needed. - I felt people would want to make an explicit choice which package to go with, if they had both atop and pcp-system-tools / pcp-atop previously, and not be forced to go with one over the other (or silently "upgraded" to one). That feels like a very aggressive upgrade to me and IMO is not appropriate here. atop is a perfectly capable standalone tool (obviously, it has its own on-disk format - the primary difference to pcp-atop) and we cannot tell which is going to be the right choice for each person at rpm install time. I'm sorry to hear about these rpm update difficulties. I'm hopeful the packaging tweak we've made for pcp-7.2.1 will make the situation more clear, as per the original request in this BZ. cheers.
Well, opting out would have meant to uninstall pcp-system-tools-7.1.5-3.fc44.x86_64 which in turn would also mean losing tools that are only available in that package. Or maybe they are available separately and I don't know about it. Making an explicit choice is not a bad idea and I appreciate the thought. But in that case there should have been some sort of notification, help text, or whatnot. Just throwing a conflict w/o further explanation is rather confusing (and annoying ;-)). But maybe the dnf/rpm system does not provide such options. And as Kai mentioned, a bail out before the actual install might be a better way to handle this. Don't get me wrong, I certainly understand that in situations like this there are always trade-offs so please don't take my comments too much to heart. I have to admit that I did not take all the possible reasons into account.
Hi guys, can not we just make the pcp-atop optional for pcp-system-tools package? In the build/rpm/redhat.spec file in "%package system-tools" section, we can have the pcp-atop as "Recommends" instead of "Requires". Then in the "%package atop" section we can remove "Obsoletes: atop" and "Provides: atop" while leaving "Conflicts: atop". Drafting a patch, it will look like this: --- a/build/rpm/redhat.spec +++ b/build/rpm/redhat.spec @@ -2163,7 +2163,7 @@ License: GPL-2.0-or-later Summary: Performance Co-Pilot (PCP) System and Monitoring Tools URL: https://pcp.io Requires: pcp = %{version}-%{release} pcp-libs = %{version}-%{release} -Requires: pcp-atop = %{version}-%{release} +Recommends: pcp-atop = %{version}-%{release} Requires: pcp-htop = %{version}-%{release} Obsoletes: pcp-system-tools-debuginfo < %{version}-%{release} %if !%{disable_python3} @@ -2183,8 +2183,11 @@ License: GPL-2.0-or-later Summary: Performance Co-Pilot (PCP) top-like system and process monitor URL: https://pcp.io Requires: pcp-libs = %{version}-%{release} -Provides: atop = %{version}-%{release} -Obsoletes: atop <= 2.12 Conflicts: atop IMO this solution will keep mutual exclusivity, while with pcp-atop optional can systems with classic atop still update PCP. And "Conflicts: atop" ensures it still fails early if someone tries to install both.
Sounds like a good idea to me, Jan.
OK, so I made a pull request in the upstream: https://github.com/performancecopilot/pcp/pull/2685
Nice, I also like the idea! Good call, Jan. Btw, just something that packagers might want to consider in the future: In situations like this it is perfectly valid to rename the binary (e.g.to pcp-atop). The only drawback is that the invocation via `pcp atop` would have to be mapped in the pcp code (which is not a huge code change ;-)). The binaries are basically the same except the ondisk data format. In many cases people would not care about the format, but I can come up with at least one scenario where it matters and people wanted to use both. (I was in the DB2 Performance team at the IBM Toronto Lab for many years.) Also, the atop code was modified to have a compatible ondisk format with the pcp framework, thus it is a pcp version of atop which makes using pcp-atop as binary name valid and appropriate. The current solution makes the use of the packages mutually exclusive. Not that it would stop me. I could always compile a version myself or create a new package. I am just throwing out some ideas here. This is not a call for a revolution. ;-) But using different binary names for tools that might have a valid reason to coexist is not such a dumb idea, is it? As I have mentioned before, this is just an idea for similar situations in the future.
Please can you provide a solution that enables system update again as soon as possible? We have currently 573 packages waiting for updates on Fedora 44 systems, that cannot be installed because the dnf transaction is aborted because of the conflict between currently installed packages atop and pcp. # LANG=C dnf upgrade -y Updating and loading repositories: Repositories loaded. ... Installing dependencies: pcp-atop x86_64 0:7.2.0-1.fc44 updates 387.7 KiB pcp-dstat x86_64 0:7.2.0-1.fc44 updates 165.7 KiB pcp-htop x86_64 0:7.2.0-1.fc44 updates 339.7 KiB pcp-selinux-import x86_64 0:7.2.0-1.fc44 updates 12.3 KiB ... [573/573] Total 100% | 0.0 B/s | 0.0 B | 00m14s Running transaction Transaction failed: Rpm transaction failed. Warning: skipped OpenPGP checks for 2 packages from repository: ims-extras - file /etc/sysconfig/atop from install of pcp-atop-7.2.0-1.fc44.x86_64 conflicts with file from package atop-2.13.0-1.fc44.x86_64 - file /usr/bin/atop from install of pcp-atop-7.2.0-1.fc44.x86_64 conflicts with file from package atop-2.13.0-1.fc44.x86_64 - file /usr/bin/atopsar from install of pcp-atop-7.2.0-1.fc44.x86_64 conflicts with file from package atop-2.13.0-1.fc44.x86_64 - file /usr/lib/systemd/system/atop.service from install of pcp-atop-7.2.0-1.fc44.x86_64 conflicts with file from package atop-2.13.0-1.fc44.x86_64 - file /usr/share/man/man1/atop.1.gz from install of pcp-atop-7.2.0-1.fc44.x86_64 conflicts with file from package atop-2.13.0-1.fc44.x86_64 - file /usr/share/man/man1/atopsar.1.gz from install of pcp-atop-7.2.0-1.fc44.x86_64 conflicts with file from package atop-2.13.0-1.fc44.x86_64
Until pcp-7.2.1 releases, a manual intervention to select either atop or pcp-system-tools and pcp-atop is required to enable system updates again, in the case of existing systems with both versions of atop installed. We'll get the pcp-7.2.1 release made as soon as we are able.
Thanks for working on a solution. On system where I have online access (server, desktop) I have removed package atop. But on laptops that are lent to employees or students I have no possibility to remove a package. The have stopped installing upgrades until the conflicting packages on fedora repositories are removed.
Yep, understood.
FEDORA-2026-4eb964e77d (pcp-7.2.0-2.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-4eb964e77d
FEDORA-2026-aa87179d7a (pcp-7.2.0-2.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-aa87179d7a
FEDORA-2026-1444df1a13 (pcp-7.2.0-2.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-1444df1a13
FEDORA-2026-4eb964e77d (pcp-7.2.0-2.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
@edgar.hoch.de , @tessarek , @kai - I have updated the PCP package as described in Comment #7. Can anyone of you, please, have a look and provide karma to https://bodhi.fedoraproject.org/updates/FEDORA-2026-1444df1a13 and/or https://bodhi.fedoraproject.org/updates/FEDORA-2026-aa87179d7a ?
(In reply to Jan Kurik from comment #19) > @edgar.hoch.de , @tessarek , > @kai - I have updated the PCP package as described in Comment > #7. Can anyone of you, please, have a look and provide karma to > https://bodhi.fedoraproject.org/updates/FEDORA-2026-1444df1a13 and/or > https://bodhi.fedoraproject.org/updates/FEDORA-2026-aa87179d7a ? Please tell me how. A `dnf update --enablerepo=updates-testing --refresh` still retrieves 0:7.2.0-1.fc44
Thanks for the fast update! I have tested it for Fedora 43 and 44. It works, dnf upgrade have installed all the pending updates packages.
FEDORA-2026-aa87179d7a (pcp-7.2.0-2.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-1444df1a13 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-1444df1a13` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-1444df1a13 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-1444df1a13 (pcp-7.2.0-2.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.