-
Notifications
You must be signed in to change notification settings - Fork 17
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
libzypp/libdnf backend exchangeability #145
Comments
Note that suseconnect-ng doesn't use libzypp directly but rather calls zypper and parses the xml output. |
Hello @skazi0 thank you for correction. The end goal is to be able to run suseconnect-ng on top of system which has dnf5 instead of zypper. |
It would also be beneficial to be able to do this for connecting EL systems to SCC directly for Liberty Linux customers. |
Here's the rhsm variant of the plugin for dnf5: https://github.com/rpm-software-management/dnf5/blob/main/libdnf5-plugins/rhsm/rhsm.cpp And here's the variant of the plugin for older libdnf: https://github.com/rpm-software-management/libdnf/blob/dnf-4-master/plugins/rhsm.cpp |
Related addition of suseconnect-ng to Fedora https://bugzilla.redhat.com/show_bug.cgi?id=2241356 |
Similar to yast/yast-packager#622
Hello, this one is one of two requests split from https://code.opensuse.org/leap/features/issue/1
The direction that SUSE seemed to agree upon regarding fate of DNF in ALP (PED-163) is to support the community to swap libdnf and libzypp backends.
@Conan-Kudo mentioned that there are two components that seem to be problematic to swap which is yast* and suseconnect-ng.
We'd like to use this tracker for work related to the exchangeability of libzypp and libdnf backends in suseconnect-ng
The text was updated successfully, but these errors were encountered: