Open FelipeRuizGarcia opened 3 months ago
What do you think ? please provide feedback. @gridhead @onuralpszr
@FelipeRuizGarcia Apologies for the delayed reply - Let's do it.
Resources
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.
@FelipeRuizGarcia DNF5 seems to be the default in F41. Giving it a try now.
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.
It still seems to be a bit early.
Installing
python3-dnf5
would require me to override thednf5
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.
@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.
In my opinion, I have been using dnf5 for several months with Fedora Rawhide, and I find it quite stable. We could consider starting to develop stable libraries or beta versions of dnf5 and its derivatives.
To prevent issues with dnf5, we can use a virtual machine or containers. Personally, I use the nightly binaries of dnf5, and they work well. For development purposes, we could create a new branch to ensure no-riak and assume that, in the future, dnf5 and its derivatives will be stable. Additionally, as we develop and release the first beta of the auto installer using dnf5, we can conduct tests with the 'migration'.
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.