We are looking at ways to make it easier to have gratis, self-supported Red Hat Enterprise Linux containers on Fedora Silverblue and Workstation. This includes Toolbx containers created with: $ toolbox create --distro rhel --release 9.3 See: https://pagure.io/fedora-workstation/issue/391 One way of doing that is to join the Red Hat Developer Program and register the Fedora host with: $ sudo subscription-manager register However, subscription-manager includes %{_bindir}/dnf-3 and %{_bindir}/dnf4 in its dependency chain. This means that installing subscription-manager on Fedora Silverblue will pull them in, and we don't want to have these executables on Silverblue because they don't work there. See: https://github.com/fedora-silverblue/issue-tracker/issues/521 This is making it difficult for us to design something that works out of the box. Would it be possible to drop %{_bindir}/dnf-3 and %{_bindir}/dnf4 from the dependencies of subscription-manager? Note that since this is Fedora, we don't care about the host's registration for its own sake. It's only about propagating the registration into the UBI containers. As far as I can make out, these files are part of python3-dnf, which is a bit odd because it sounds like the package is about the Python APIs for DNF, and not the actual executables. Reproducible: Always
(In reply to Debarshi Ray from comment #0) > However, subscription-manager includes %{_bindir}/dnf-3 and %{_bindir}/dnf4 > in its dependency chain. This means that installing subscription-manager on > Fedora Silverblue will pull them in, and we don't want to have these > executables on Silverblue because they don't work there. subscription-manager needs python3-dnf for two things: - it ships plugins for dnf - for the package profile, i.e. the list of packages installed & modules updated on the system, that is periodically sent to the registration server Apparently python3-dnf ships also the actual dnf executable, which seems to be a very light > Would it be possible to drop %{_bindir}/dnf-3 and %{_bindir}/dnf4 from the > dependencies of subscription-manager? Unfortunately not directly, since those executables are in a Python module package. What you can try doing is disabling the dnf support entirely in the subscription-manager packaging. In the spec file you see: %global use_dnf (0%{?fedora} || (0%{?rhel})) so simply ensure that this "use_dnf" variable is false. Not sure whether there is a way to have changes specific for Silverblue.
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
(In reply to Pino Toscano from comment #1) > (In reply to Debarshi Ray from comment #0) > > Would it be possible to drop %{_bindir}/dnf-3 and %{_bindir}/dnf4 from the > > dependencies of subscription-manager? > > Unfortunately not directly, since those executables are in a Python module > package. > > What you can try doing is disabling the dnf support entirely in the > subscription-manager packaging. > In the spec file you see: > > %global use_dnf (0%{?fedora} || (0%{?rhel})) > > so simply ensure that this "use_dnf" variable is false. I had tried this before: https://bugzilla.redhat.com/show_bug.cgi?id=2246833#c5 ... and apparently it didn't work, but the problem could have been between the keyboard and the chair. :) I will try again. I am hopeful because 'sudo subscription-manager register' seems to be having the desired effect of upgrading UBI containers to RHEL on Fedora hosts with DNF5, where the DNF plugin doesn't work. See: https://bugzilla.redhat.com/show_bug.cgi?id=2246833#c12
(In reply to Pino Toscano from comment #1) > Not sure whether there is a way to have changes specific for Silverblue. A solution that works best for both Fedora Silverblue and Workstation is probably the best. There are some ways to make Silverblue and Workstation specific changes by tweaking the definition of which RPMs go into their default images, or by messing with the fedora-workstation-* and fedora-release-* RPMs. I can't think of anything else off the top of my head.
Here's an initial pull request: https://github.com/candlepin/subscription-manager/pull/3509
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.
(In reply to Debarshi Ray from comment #8) > Here's an initial pull request: > https://github.com/candlepin/subscription-manager/pull/3509 The pull request is ready for review. Scratch build for Fedora 41: https://koji.fedoraproject.org/koji/taskinfo?taskID=129685506 Scratch build for Fedora 40: https://koji.fedoraproject.org/koji/taskinfo?taskID=129686046 I tested these two builds on Fedora 40 and 41 Silverblue and Workstation. I verified that: * No DNF executable gets pulled into Silverblue, because which dnf and rpm --query --all | grep --ignore-case dnf come up empty. * No DNF warnings on Workstation when using dnf update, etc.. * If libdnf-plugin-subscription-manager is present from a previous installation of subscription-manager then it gets removed after an update. There was one instance where a UBI container was refusing to get upgraded to RHEL even when the Fedora host was registered, but it started working before I could investigate in detail. What's the best way to debug these cases? Check /run/secrets inside the container and /usr/share/rhel/secrets on the host?