Proposal: Implement libdnf5 API in Python for Future Commands and Phase Out dnf commands

[FelipeRuizGarcia]

Implement libdnf5 API

This PR intends to discuss the next steps regarding the integration of the libdnf5 API in Python to replace the current use of dnf commands. Additionally, it proposes phasing out the dnf5 plugin to accommodate the expansion to more commands beyond package management, as nvidia-open etc.

Open GPU kernel modules versus Proprietary drivers
https://github.com/NVIDIA/open-gpu-kernel-modules

Motivation:

Flexibility: The libdnf5 API offers a more flexible and programmable approach, allowing us to add new features and commands without relying on external command-line tools.

Future Expansion: Moving away from dnf5 plugins will open the door for broader functionality beyond the scope of traditional dnf operations.

https://dnf5.readthedocs.io/en/latest/api/index.html

https://github.com/rpm-software-management/dnf5/tree/main

Implement libdnf5 API:

Transition from using dnf at the command level to utilizing the libdnf5 API in Python.
This change is aimed at making the tool more adaptable for future developments and expanding beyond package management.

Next Steps:

Begin the integration process by replacing existing dnf command calls with corresponding libdnf5 API calls.

Gradually phase out the dnf5 plugin while ensuring backward compatibility during the transition period.

Document the new API usage and update any related documentation or scripts.

With the flexibility of the API, adding more features to configure repositories and packages becomes straightforward. For example, enabling Fedora Rawhide repositories.

[FelipeRuizGarcia]

What do you think ? please provide feedback.
@gridhead @onuralpszr

[gridhead]

@FelipeRuizGarcia Apologies for the delayed reply - Let's do it.

[gridhead]

Resources

• https://dnf5.readthedocs.io/en/latest/api/index.html
• https://dnf5.readthedocs.io/en/latest/api/python/python.html
• https://rpmfusion.org/Howto/NVIDIA
• Gotta retain executable permission for the binary after the builds are compressed
• Gotta have 100% test coverage of the functional codebase

[gridhead]

On closer inspection - I'd like to wait until Fedora Linux 42 when DNF5 will become the norm. Jumping the gun could result disastrously on users as the dnf5 will have an overriding effect on the default dnf whenever the installation of this package leads to the installation of the libdnf dependency.

[gridhead]

@FelipeRuizGarcia DNF5 seems to be the default in F41. Giving it a try now.

[gridhead]

It still seems to be a bit early.

Installing python3-dnf5 would require me to override the dnf5 installed on system packages with the one I acquired from the COPR namespace of RPM Software Management. I would strongly discourage doing this and would much rather wait for one more release before this is normally available in the official Fedora Linux repositories.

[onuralpszr]

It still seems to be a bit early.

Installing python3-dnf5 would require me to override the dnf5 installed on system packages with the one I acquired from the COPR namespace of RPM Software Management. I would strongly discourage doing this and would much rather wait for one more release before this is normally available in the official Fedora Linux repositories.

We don't need to wait for this, have distrobox we have toolbox we have devcontainer to work with it. It should be fairly easy to start develop without change your system dnf5 package etc.

[gridhead]

@onuralpszr It will still require the same to be installed on their systems too. Messing with their package managers is something I do not encourage.