spec: Avoid DNF warnings on traditional Fedora hosts and DNF on atomics

[debarshiray]

Goes on top of #3517

It will be good to make it easier to have gratis, self-supported Red Hat Enterprise Linux OCI containers on Fedora Silverblue and Workstation through the RHEL Developer Suite subscription. This includes Toolbx containers created with:

  $ toolbox create --distro rhel --release 9.5

However, when subscription-manager was installed on a Fedora host with DNF4, the subscription-manager DNF plugin printed some spurious warning messages that users didn't like because it made them think that something is wrong. eg., when the host is unregistered:

  $ sudo dnf update
  Updating Subscription Management repositories.
  Unable to read consumer identity

  This system is not registered with an entitlement server. You can use
      subscription-manager to register.

  Last metadata expiration check: ...

Or, when the host has been registered:

  $ sudo dnf update
  Updating Subscription Management repositories.

  This system is registered with an entitlement server, but is not
      receiving updates. You can use subscription-manager to assign
      subscriptions.

  Last metadata expiration check: ...

These warnings have no relevance in Fedora, because the purpose of using subscription-manager(8) on a Fedora host is to access RHEL content in OCI containers. There is no need for RHEL content on the Fedora host itself.

Note that these warnings aren't visible on Fedora hosts with DNF5 because the subscription-manager plugin doesn't work with it.

Secondly, until now, subscription-manager had %{_bindir}/dnf-3 and %{_bindir}/dnf4 in its dependency chain. This meant that installing subscription-manager on Fedora Silverblue pulled them in, even though those executables shouldn't be present on Silverblue because they don't work there.

Both these problems can be addressed by disabling the DNF and libdnf plugins on Fedora.

https://bugzilla.redhat.com/show_bug.cgi?id=2246833
https://bugzilla.redhat.com/show_bug.cgi?id=2262228

[debarshiray]

Here is an initial scratch build for Fedora 41:
https://koji.fedoraproject.org/koji/taskinfo?taskID=129215936

It seems to work. I am now trying to ensure that libdnf-plugin-subscription-manager isn't left behind after updating subscription-manager.

[debarshiray]

Did a trivial git rebase on top of main.

[debarshiray]

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

[debarshiray]

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?

[debarshiray]

I dropped the CMake fix from #3521 in favour of #3522 as suggested in #3518

[debarshiray]

Rebased on top of main.

[ptoscano]

Hi @debarshiray,

sorry for the late answer. I provided some notes regarding the actual implementation of the changes in the spec file; regarding the changes in behaviour, let me provide a bit more context and explanations.

However, when subscription-manager was installed on a Fedora host with DNF4, the subscription-manager DNF plugin printed some spurious warning messages that users didn't like because it made them think that something is wrong. eg., when the host is unregistered:

Strictly speaking, this behaviour is correct: by default the dnf plugins of subscription-manager are installed with subscription-manager and enabled by default, because the assumption is that subscription-manager is used to register the current system and provide content for it. This assumption is generally correct on RHEL, where subscription-manager is installed by default and used as tool to get content from a registration server (Red Hat's Hosted RHSM, Katello/Satellite, a self-deployed Candlepin). Other EL systems usually need subscription-manager for registering with the purpose of converting the system to RHEL, so the sitation is fine there too. On Fedora though the situation is a bit more fuzzy.

These warnings have no relevance in Fedora, because the purpose of using subscription-manager(8) on a Fedora host is to access RHEL content in OCI containers. There is no need for RHEL content on the Fedora host itself.

Yes, and also no. What you mention is one use case, and most likely the most visible from an user POV. OTOH, subscription-manager is not only for "RHEL content" -- it does not even know what gets from the registration server in terms of entitlement certificates available (i.e. those used by dnf to access content), and it simply unpacks the available content into a redhat.repo file. There is no detection of content whatsoever.

subscription-manager is also developed on Fedora, registering to any of the possibilities I mentioned above (RHSM, Katello/Satellite, own Candlepin), and getting content as advertized by that registration server. Katello/Satellite can actually provide content for Fedora systems (and even to Debian-based systems, yes!), and so a self-deployed Candlepin. The latter is especially important for testing subscription-manager easily in an upstream context, ensuring it is working on each new Fedora version, and thus saving a lot of troubles for future RHEL versions. The dnf plugins are an essential part of this flow, and they do need testing as well (yes, the fact that currently the subscription-manager dnf plugins in F41+ are non-functional because they are for dnf4 and F41+ has dnf5 is a problem, although a different one).

As I mentioned above, the dnf plugins are enabled by default -- you can see their configurations here:
https://github.com/candlepin/subscription-manager/tree/3eb3ca50939ebf7b177bdaa1d10a74095ebbe33e/etc-conf/plugin
One option could be to disable them by default in Fedora. In this case, there is a configuration option of subscription-manager that enables them automatically after a successfull registration:

subscription-manager/etc-conf/rhsm.conf

Lines 70 to 71 in 3eb3ca5

	# Manage automatic enabling of yum/dnf plugins (product-id, subscription-manager)
	auto_enable_yum_plugins = 1

(i.e. auto_enable_yum_plugins in rhsm.conf)

Back to this PR in its current form: while I agree the situation can be improved, I don't agree with the proposed solution. As explained above about testing, it is important to keep subscription-manager working and usable on Fedora, and this PR practically stop shipping the dnf plugins at all on Fedora. I don't find it acceptable, as it does not allow to even enable the "full subscription-manager flow" on Fedora even if wanted, as the plugins would not be there. What I can propose instead is to tweak both the configurations of the plugins and rhsm.conf so that the dnf plugins are not enabled by default and not enabled automatically on registration, doing that during the package build on the files as installed in %{buildroot} (i.e. not touching the source files), and only on Fedora (or generalizing it with a %global RPM variable for this behaviour).

[ptoscano]

rather than overloading/nesting this %if (which is documented to be only for use_container_plugin, simply change the definition of the %global use_dnf below, removing the fedora check

[ptoscano]

unrelated, please remove; while I get you need it for local testing, it is not needed upstream

[ptoscano]

it seems like this %if ought to use an existing variable (use_dnf, I think?), rather than duplicating a condition

[jirihnidek]

This commit is probably in conflict with main branch and it is not needed anymore. This block was moved. See: 518a929

[debarshiray]

Hi @debarshiray,

sorry for the late answer. I provided some notes regarding the actual implementation of the changes in the spec file; regarding the changes in behaviour, let me provide a bit more context and explanations.

[...]

Back to this PR in its current form: while I agree the situation can be improved, I don't agree with the proposed solution. As explained above about testing, it is important to keep subscription-manager working and usable on Fedora, and this PR practically stop shipping the dnf plugins at all on Fedora. I don't find it acceptable, as it does not allow to even enable the "full subscription-manager flow" on Fedora even if wanted, as the plugins would not be there. What I can propose instead is to tweak both the configurations of the plugins and rhsm.conf so that the dnf plugins are not enabled by default and not enabled automatically on registration, doing that during the package build on the files as installed in %{buildroot} (i.e. not touching the source files), and only on Fedora (or generalizing it with a %global RPM variable for this behaviour).

Thanks for the review, and explaining everything!

Other than the issue of the DNF warning messages that people complain about, there is the problem that subscription-manager has %{_bindir}/dnf-3 and %{_bindir}/dnf4 in its dependency chain (at least on operating systems with DNF4 - I have to check what the situation is with DNF5).

This is a problem on atomic or image-based variants of Fedora, like Silverblue, because they want to manage the OS image with rpm-ostree, not DNF4. These days there's a transition from rpm-ostree to bootc and DNF5 is supposed to play the role of rpm-ostree on bootc-based OSes. However, Fedora Silverblue still defaults to rpm-ostree, and that's why I wanted to avoid having DNF in the dependency chain.

I am thinking of building the DNF and libdnf plugins on Fedora, but not installing them by default with the subscription-manager RPM. We can put them in a separate subpackage, and someone who wants to use a registration server to manage a Fedora host can explicitly install that separate subpackage. The subscription-manager RPM wouldn't even have a weak dependency on the subpackage because on Fedora dnf install pulls in the weak dependencies by default. In practical terms this would mean using the dnf-plugin-subscription-manager subpackage.

What do you think?

[jirihnidek]

There are conflicts with main branch. Please resolve these conflicts. The most of issues have been resolved in this PR: #3525

I think that we cannot drop support for dnf4 plugins so easily, because dnf4 can be still installed on Fedora41, despite dnf5 is installed by default. It seems that dnf4 will be also possible to install on Fedora42.

[jirihnidek]

This commit is probably in conflict with main branch and it is not needed anymore. This block was moved. See: 518a929

[debarshiray]

Thanks for the review, @jirihnidek !

I think that we cannot drop support for dnf4 plugins so easily, because dnf4 can be still installed on Fedora41, despite dnf5 is installed by default. It seems that dnf4 will be also possible to install on Fedora42.

I see.

What do you think of my other idea above to keep the DNF and libdnf plugins on Fedora, but not installing them by default with the subscription-manager RPM?