glibc provides and installs binary or binaries in `/sbin` (e.g. `/sbin/ldconfig`). In nowadays it is supposed to have binaries in `/usr/sbin/` (see Fedora 17 proposal https://fedoraproject.org/wiki/Features/UsrMove). Why this is important? 1. dnf cannot find what provides binary, because it is not in standard location $ dnf provides ldconfig 2. DNF5 as a replacement of DNF will not download filelists by default therefore there will be a problem with broken dependencies for several packages. See https://bugzilla.redhat.com/show_bug.cgi?id=2180842. May I ask you to install binaries to `/usr/sbin/`, but for compatibility reasons please keep the original provide using `Provides: /sbin/ldconfig` Reproducible: Always
I suppose we can add this: Provides: /sbin/ldconfig Provides: /usr/sbin/ldconfig Such a change doesn't require us to fix bug 1063607, which has been open for so long that it is unreasonable to expect a fix anytime soon. Would that meet your requirement?
(In reply to Florian Weimer from comment #1) > I suppose we can add this: > > Provides: /sbin/ldconfig > Provides: /usr/sbin/ldconfig > > Such a change doesn't require us to fix bug 1063607, which has been open for > so long that it is unreasonable to expect a fix anytime soon. > > Would that meet your requirement? The proposed solution will resolve our issue in bug 2180842 but does not resolve the issue from bug 1063607. Therefore from my side the solution meets our requirement and I will be happy to see it in Fedora. Thank you very much for your fast response.
(In reply to Jaroslav Mracek from comment #2) > (In reply to Florian Weimer from comment #1) > > I suppose we can add this: > > > > Provides: /sbin/ldconfig > > Provides: /usr/sbin/ldconfig > > > > Such a change doesn't require us to fix bug 1063607, which has been open for > > so long that it is unreasonable to expect a fix anytime soon. > > > > Would that meet your requirement? > > The proposed solution will resolve our issue in bug 2180842 but does not > resolve the issue from bug 1063607. > > Therefore from my side the solution meets our requirement and I will be > happy to see it in Fedora. Thank you very much for your fast response. Could you please test the new update and tell us if this fixes the issue? https://bodhi.fedoraproject.org/updates/FEDORA-2023-a4bcc99f09 Thank you!
It works like a charm in Fedora 39. May I ask you to back-port the solution to Fedora 38? In Fedora 38, DNF5 already replaced microdnf, therefore the issue is valid there.
(In reply to Jaroslav Mracek from comment #4) > It works like a charm in Fedora 39. May I ask you to back-port the solution > to Fedora 38? In Fedora 38, DNF5 already replaced microdnf, therefore the > issue is valid there. We are going to bundle this with further updates in Fedora 38. Do we need to backport this further? I think if we ever want to switch to DNF5 for mock and DNF5 cannot even install the bootstrap root, then we'll need a different approach. If the bootstrap roots are fine, I don't think we have to fix older branches/z-streams.
FEDORA-2023-1e4a05f40b has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-1e4a05f40b
FEDORA-2023-1e4a05f40b has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-1e4a05f40b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-1e4a05f40b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-1e4a05f40b has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
I believe that Fedora 38+ is sufficient.