gridhead / nvidia-auto-installer-for-fedora-linux

A CLI tool which lets you install proprietary NVIDIA drivers and much more easily on Fedora Linux (32 or above and Rawhide)
https://ask.fedoraproject.org/t/nvidia-auto-installer-for-fedora-linux-now-works-with-fedora-linux-36/22310/
GNU General Public License v3.0
507 stars 28 forks source link

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

Open FelipeRuizGarcia opened 3 months ago

FelipeRuizGarcia commented 3 months ago

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 commented 3 months ago

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

gridhead commented 2 months ago

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

gridhead commented 2 months ago

Resources

gridhead commented 2 months ago

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 commented 3 weeks ago

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

gridhead commented 3 weeks ago

It still seems to be a bit early.

{99D35AEA-4D37-4DDD-AE08-60F9D0DB8F71}

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 commented 3 weeks ago

It still seems to be a bit early.

{99D35AEA-4D37-4DDD-AE08-60F9D0DB8F71}

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 commented 3 weeks ago

@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.

FelipeRuizGarcia commented 3 weeks ago

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'.