-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No more dnf, change to installpkg python3-dnf
#1423
Conversation
The dnf team wants to drop the 'dnf' binary package, see https://src.fedoraproject.org/rpms/dnf/c/51ac29c . However, this makes lorax blow up because of this line, see https://bodhi.fedoraproject.org/updates/FEDORA-2024-a7176faa5b#comment-3745816 Let's change it to python3-dnf , which should work so long as everything in the installer uses the Python interface and nothing calls 'dnf' directly. Signed-off-by: Adam Williamson <awilliam@redhat.com>
Pull Request Test Coverage Report for Build 11078210209Details
💛 - Coveralls |
Hm. I wonder if we can remove it completely? dnf should be requiring everything it needs. It is also possible that people used it in kickstarts for whatever reasons, so replacing it with the library won't help there. |
eh? not quite sure I follow. AFAICS the reason it's here is for anaconda to use it. replacing it with python3-dnf is so anaconda still has the bit it actually needs (the Python interface) to use. if we remove it entirely, and it isn't pulled in by some other dep, anaconda will definitely break. dnf5 does not depend on python3-dnf because that's the old interface, dnf5 uses the new libdnf. anaconda has not been ported to the new libdnf python bindings, though, it still needs the old interface, which is why we still have python3-dnf. |
I can run a scratch build of this and test it to see if it blows up in a default install, anyhow. |
That passed, so this is OK at least for a straightforward default interactive network install. |
I'm not sure what "installer" means here. Is it lorax which creates installation media? Or is it Anaconda which is executed from installation media and installs the target system? I believe that Anaconda only uses "dnf" library. That is packaged in python3-dnf package on all Fedoras. If something needs to execute DNF4 program, then since Fedora 41 it needs to execute /usr/bin/dnf-3 (or /usr/bin/dnf4) from python3-dnf package. See "Anaconda" section in https://fedoraproject.org/wiki/Changes/SwitchToDnf5. |
@ppisar in the context of the commit description, "installer" refers to anaconda, yes. |
There's no need to change it to anything, python3-libdnf is being pulled in by something else requiring it. Closing in favor of #1424 |
mmm. okay. but in that case we should make sure anaconda requires python3-dnf somewhere or else we are just relying on some random dep of something else which might disappear at any time. edit: it looks like anaconda-core does require python3-dnf , so we should be good. |
The dnf team wants to drop the 'dnf' binary package, see https://src.fedoraproject.org/rpms/dnf/c/51ac29c . However, this makes lorax blow up because of this line, see
https://bodhi.fedoraproject.org/updates/FEDORA-2024-a7176faa5b#comment-3745816 Let's change it to python3-dnf , which should work so long as everything in the installer uses the Python interface and nothing calls 'dnf' directly.