I have the Hashicorp Vault repo installed and I've been running what I thought to be a Vault cluster. However, it appears that dnf-automatic will replace vault with openbao. 1) Install the vault package from Hashicorp's official repo # dnf history info 15 Description : ansible dnf5 module Comment : Packages altered: Action Package Reason Repository Install vault-0:1.20.3-1.x86_64 User hashi 2) Attempt your automatic updates [root@vault-β log]# dnf history info 20 Transaction ID : 20 Begin time : 2025-09-18 06:25:16 Begin rpmdb : b9f9f3d3e862210946a7a550710e77d8e74dca4a8a844a1c8de356020931f33e End time : 2025-09-18 06:25:39 End rpmdb : d93318a9af2d05f4680d6ac22de861644029a327c4aa0557a8df524facfb8b49 User : 0 Super User <root> Status : Error Releasever : 42 Description : /usr/bin/dnf5 automatic --timer Comment : Packages altered: Action Package Reason Repository Install openbao-vault-compat-0:2.4.1-1.fc42.x86_64 User updates Install openbao-0:2.4.1-1.fc42.x86_64 Dependency updates Replaced vault-0:1.20.3-1.x86_64 User @System The resulting transaction will fail, as it does when you try to install vault manually: # dnf install vault # >>> [RPM] unpacking of archive failed on file /etc/vault.d;68d1ff2f: cpio: File from package already exists as a directory in system >>> Unpack error: openbao-vault-compat-0:2.4.1-1.fc42.x86_64 But it does enough to break Vault. And it gets even more confusing because the openbao package doesn't replace the vault unit file. Would it be possible to add some kind of logic to the openbao package so it doesn't try to install itself over an existing vault? Thanks for your time, ~ Brian Reproducible: Always Steps to Reproduce: 1. See above, install vault from the hashicorp repo 2. Attempt to update vault Actual Results: The original vault package should have been updated Expected Results: DNF replaced Hashicorp Vault with OpenBao
Where are the instructions to install hashicorp vault on fc42 so I can reproduce? I would like for someone who does not have vault installed to be able to do "dnf install vault" and get openbao-vault-compat, if that can be done without causing a problem for those who already have vault. Maybe I could just change the "Obsoletes: %{oldname} < 2.0" to "Conflicts: %{oldname} < 2.0" but I would like to test it.
Hmm, the podman-docker package in https://src.fedoraproject.org/rpms/podman/blob/rawhide/f/podman.spec#_128 only says "Conflicts: docker" and doesn't even do "Provides: docker" but "dnf install docker" gets the package. I guess dnf is finding the /usr/bin/docker and making that match.
Hello Dave, Thanks for the quick response and apologies for not providing more info on the Hashicorp Vault repo. Directions for installing the Hashicorp RPM repo are here: https://www.hashicorp.com/en/blog/announcing-the-hashicorp-linux-repository Once the repo is installed, you can install as usual with `dnf install vault`. To avoid package conflicts, you can do something like `dnf --disablerepo=* --enablerepo=hashicorp install vault` Please let me know if you need more info. Best, ~Brian
Provides are the correct method to be able to install a package by an alternate name. Dave, I can't reproduce the behavior you're describing with podman-docker. `dnf install docker` resolves to moby-engine, which provides the name docker but doesn't obsolete it. This has nothing to do with the /usr/bin/docker path. root@f44:~# dnf -q repoquery --whatobsoletes docker root@f44:~# dnf -q repoquery --whatprovides docker moby-engine-0:28.4.0-1.fc44.x86_64 root@f44:~# dnf install docker Updating and loading repositories: Repositories loaded. Package Arch Version Repository Size Installing: moby-engine x86_64 28.4.0-1.fc44 rawhide 87.7 MiB Installing dependencies: ... That said, I don't think the behavior of `dnf install vault` resulting in openbao-vault-compat being installed is appropriate. It is a valid choice for users to enable the hashicorp repo on their systems and install vault from there, and by providing that name you're forcing them to have to take extra steps to get vault, as Brian mentioned. All you need to do is have openbao-vault-compat conflict with vault due to having the same file paths. Vault wasn't previously shipped in Fedora, so there is no expecation or requirement that `dnf install vault` should work out of the box.
Ah, I wasn't testing in Fedora, I tested in el9, and there the package is provided in the appstream repo, not by EPEL. After it is installed then "rpm -q --provides podman-docker" shows docker = 5:5.4.0-13.el9_6 podman-docker = 5:5.4.0-13.el9_6 I was trying to follow the precedent of that package. Interestingly, it doesn't show anything for "--conflicts" (or "--obsoletes"). Oh, but there is a difference, in that the name of the original docker package is actually docker-ce, not docker. Alright, I'll change it to only be conflicts.
FEDORA-EPEL-2025-15f0681ccd (openbao-2.4.1-2.el8) has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-15f0681ccd
FEDORA-2025-d1f388148b (openbao-2.4.1-2.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-d1f388148b
FEDORA-EPEL-2025-653cf73191 (openbao-2.4.1-2.el9) has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-653cf73191
FEDORA-EPEL-2025-35c2710c80 (openbao-2.4.1-2.el10_0) has been submitted as an update to Fedora EPEL 10.0. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-35c2710c80
FEDORA-2025-763a968fdd (openbao-2.4.1-2.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-763a968fdd
FEDORA-EPEL-2025-15f0681ccd has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-15f0681ccd See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-653cf73191 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-653cf73191 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-cae78f0c4d has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-cae78f0c4d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-cae78f0c4d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-1474c26e96 has been pushed to the Fedora EPEL 10.2 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-1474c26e96 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-35c2710c80 has been pushed to the Fedora EPEL 10.0 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-35c2710c80 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-da129c5ff8 has been pushed to the Fedora EPEL 10.1 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-da129c5ff8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-763a968fdd has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-763a968fdd` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-763a968fdd See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-d1f388148b has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-d1f388148b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-d1f388148b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Fedora Update System from comment #17) > FEDORA-2025-763a968fdd has been pushed to the Fedora 42 testing repository. > Soon you'll be able to install the update with the following command: > `sudo dnf upgrade --enablerepo=updates-testing --refresh > --advisory=FEDORA-2025-763a968fdd` > You can provide feedback for this update here: > https://bodhi.fedoraproject.org/updates/FEDORA-2025-763a968fdd > > See also https://fedoraproject.org/wiki/QA:Updates_Testing for more > information on how to test updates. Brian King, if you try this and give it karma it will be promoted to the updates repository sooner.
*** Bug 2398021 has been marked as a duplicate of this bug. ***
FEDORA-EPEL-2025-653cf73191 (openbao-2.4.1-2.el9) has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
Hello Dave, Thanks for the fix! I'll check our your link and try to help out by giving karma.
FEDORA-EPEL-2025-15f0681ccd (openbao-2.4.1-2.el8) has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-cae78f0c4d (openbao-2.4.1-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-EPEL-2025-1474c26e96 (openbao-2.4.1-2.el10_2) has been pushed to the Fedora EPEL 10.2 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-da129c5ff8 (openbao-2.4.1-2.el10_1) has been pushed to the Fedora EPEL 10.1 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-35c2710c80 (openbao-2.4.1-2.el10_0) has been pushed to the Fedora EPEL 10.0 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-d1f388148b (openbao-2.4.1-2.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-763a968fdd (openbao-2.4.1-2.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.