It's not spam. It's intentional and as desired by the Fedora Workstation Working Group: https://pagure.io/fedora-workstation/issue/391

It's a weak dependency. So, you are free to remove it if you want to. It's assumed that those using the command line with strong opinions on such things will be able to do that.

I did not intend for my comment to be perceived as conflictual. I am very much in favor of facilitating the people who want to use RHEL containers and that includes me as well.

Having said that, I do not want to run any containers (or RHEL containers specifically) on most of my Fedora Workstation systems, just a couple. Frankly, I don't enjoy seeing a message that informs me of something I am well aware of, on every dnf transaction, nor do I appreciate having to jump through hoops to get rid of it. Is there a configuration option somewhere that allows me to silence it? If you are going to have that message appear forever onwards on users' screens, please do add some useful documentation (or a link to it) on what users are supposed to do about said message.

Second, wasn't this planned for F40, as per the ticket you linked to?

Third, if we're talking assumptions, it can also be assumed that people who want to use RHEL containers are usually capable of determining whether they have subscription-manager installed.

There is also an issue with this update in particular. The original transaction had these packages (sorry for the long lines):

Installing dependencies:
 libdnf-plugin-subscription-manager                                           x86_64                                       1.29.39-1.fc39                                         updates                                               146 k
 python3-cloud-what                                                           x86_64                                       1.29.39-1.fc39                                         updates                                               170 k
 python3-subscription-manager-rhsm                                            x86_64                                       1.29.39-1.fc39                                         updates                                               280 k
 subscription-manager-rhsm-certificates                                       noarch                                       20220623-3.fc39                                        fedora                                                 20 k
 virt-what                                                                    x86_64                                       1.25-4.fc39                                            fedora                                                 32 k
Installing weak dependencies:
 skopeo                                                                       x86_64                                       1:1.14.0-1.fc39                                        updates                                               8.4 M
 subscription-manager                                                         x86_64                                       1.29.39-1.fc39                                         updates                                               1.1 M

Yet if I try to remove subscription-manager, I get this:

# dnf remove subscription-manager
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.

Dependencies resolved.
================================================================================
 Package                                Arch   Version           Repo      Size
================================================================================
Removing:
 subscription-manager                   x86_64 1.29.39-1.fc39    @updates 3.7 M
Removing unused dependencies:
 libdnf-plugin-subscription-manager     x86_64 1.29.39-1.fc39    @updates  64 k
 python3-cloud-what                     x86_64 1.29.39-1.fc39    @updates  75 k
 python3-iniparse                       noarch 0.5-6.fc39        @fedora  124 k
 python3-inotify                        noarch 0.9.6-32.fc39     @fedora  302 k
 python3-subscription-manager-rhsm      x86_64 1.29.39-1.fc39    @updates 543 k
 subscription-manager-rhsm-certificates noarch 20220623-3.fc39   @fedora   27 k
 virt-what                              x86_64 1.25-4.fc39       @fedora   55 k

Transaction Summary
================================================================================
Remove  8 Packages

Why would it remove python3-iniparse python3-inotify (and virt-what)?

I don't understand why you insist on calling three extra lines in your DNF output as spam. DNF isn't a particularly terse command, and I find it odd to use the word spam in this context.

Will you still call it spam when it shows up in Fedora 40?

Second, wasn't this planned for F40, as per the ticket you linked to?

My original intent was to add it to fedora-comps for Fedora Rawhide/40 and advertise it as a Fedora Workstation feature. The discussion in the Fedora Workstation Working Group ticket felt that it's better to leave it as a toolbox package-level feature and dependency.

In fact there were suggestions to add it to even other packages like podman, systemd-container, mkosi, etc., and, even, the hypothetical case of SUSEConnect was discussed.

As the owner of the toolbox package, I do want to have the dependency in existing stable Fedoras too, because it significantly enhances the usability of Toolbx with RHEL containers. In contrast, fedora-comps is used during OS installation. There's no sense in adding to existing stable Fedoras because their installation media are not going to be regenerated. Hence, Fedora Rawhide/40 is the only option for fedora-comps.

It's a weak dependency. So, you are free to remove it if you want to.

Until it gets updated, and the weak dependencies are installed again.

Nobody is forcing you to have toolbox on your system either.

Fedora CoreOS is a genuine case that doesn't want to have subscription-manager and that's already taken care of.

Looks like Bodhi doesn't support quoting. :(

Debarshi, I double-checked my reply before submitting it, especially looking for the word "spam", as I realized that it could come off as too harsh. I apologize if my tone was offensive.

The fact of the matter is I don't mind having subscription-manager in F39 by default, nor do I care if this goes through a proper change proposal (arguably, others might). Even on systems where I don't use containers, personally I don't mind the extra space being taken up. My issue is with the message, that appears to be persistent. The value of every terminal line is quite high, even more so if you are ssh'ing into the machine. I wouldn't want dnf to inform me that I have x and y repositories disabled or that I haven't installed 'foo' in the beginning of every transaction. If that information is irrelevant to my system's "health", I do not want to be reminded every time I update, install, or remove a package.

Wouldn't you agree that a message along the lines of

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.

Please visit https://fedoraproject.org/rhel_containers_on_workstation/ for more information
or run
echo "prompt=False" > /etc/some/config/file
as root to stop seeing this message.

would be far more useful and doubly so for people who do not use containers at all?

Sorry, I wasn't fast enough in my reply, I hope I managed to properly frame the (my) issue.

Looks like Bodhi doesn't support quoting. :(

Supposedly, prefixing a line with ">" should work. At least at some point I'm almost sure it did.

Before you again use the word spam, consider this:

• You are doing a disservice to your role as a tester by actually trying to force me to ship sub-optimal software.

• Would you throw such a fit if Autoconf generated a configure script had a few extra lines of spew?

• You are trying to block something that the Fedora Workstation Working Group wants to achieve.

• You are doing this in an insidious way by taking advantage of the fact that a lot of people are already on their way out for the holidays.

“Nobody is forcing you to have toolbox on your system either.”

I am not the one labeling it as 'spam'. However, you are right; perhaps it's time to stop using the toolbox if adding superfluous output to every dnf transaction is deemed a usability improvement, regardless of whether RHEL containers are used or not.

Alex, when you hose a pending update with a deluge of negative karma, then it implies that something is very seriously wrong with the update. Arguing about three extra lines in your DNF output is nowhere close to that.

You are essentially saying that nobody can depend on Fedora's subscription-manager package, at least not any package that's sufficiently popular. At that point, we might as well force the removal of subscription-manager from Fedora.

If you want to improve the subscription-manager user interface, then that's fine. I can think of several improvements to it. However, it's quite absurd to hold a toolbox update hostage over deficiencies in the subscription-manager UI.

Those extra three lines are nowhere close to being considered serious breakage. Are they causing data loss? Are they preventing machines from booting and updating? DNF generates dozens if not hundreds of lines, and it's output has changed and swollen over the years. Lots of terminal programs lead to lots of spew. Take any build system for example.

While we haggle over this, there are several users who really want to be able to access a RHEL user space environment on Fedora - either for upstream maintenance or Fedora EPEL work or RHEL work. To do that they need a way to update their UBI Toolbx containers to RHEL.

Zeno, you are coming across as a spammer here.

So far, you have contributed nothing other than a couple of passive aggressive comments. If you were genuine in your desire to improve Fedora, then you could have submitted a subscription-manager issue to streamline their output. Have you done that?

“If you were genuine in your desire to improve Fedora, then you could have submitted a subscription-manager issue to streamline their output. Have you done that?”

No, because there already is one: https://bugzilla.redhat.com/show_bug.cgi?id=2246833

Labeling me as a spammer and assuming my comments are passive-aggressive is a little too far though. I was responding to your comment “Nobody is forcing you to have toolbox on your system either.” which could be labeled as passive-aggressive.

By the way, you can disable the DNF plugin shipped by subscription-manager by editing /etc/dnf/plugins/subscription-manager.conf.

Now you can say that it could be advertised or documented better, but it's not exactly hidden either. It's pretty easy to spot if you do a ls --recursive /etc/dnf.

Zeno, so why have you not participated there on the subscription-manager issue? Or are you waiting to attack the next package that happens to rely on subscription-manager.

You are a spammer who is spamming this update, and you literally borked it without adding anything new to the discussion. Then you topped it up with a bunch of snarky and aggressive comments. You are mistaken if you think that I won't call you out on that.

The link to that subscription-manager issue is the first useful information that you shared.

Addressing your points:

• The single use of "spam" as a verb was from my brain being lazy late at night, trying to describe an unsolicited, repetitive message. I apologized for that.

• I expect anything like what you describe when using Autoconf. When I am using dnf however, which is the only method I use to perform package transactions on my systems, I do not. I don't know how to make this clearer: it's as if whenever I'm playing a song in Audacious, a voice pops over it saying "Audacity is not installed on this system".

• I am not trying to block something that the Fedora Workstation Working Group wants to achieve, even though the SIG's intents are not scripture and everything should be up for discussion. Like I said, I too want to be able to use RHEL containers on Fedora.

• Let's tone down the adjectives a bit, shall we? I'm not going to touch the rest of that sentence.

I caught the messages that came in the meantime, a few more points.

When negative karma is given to an update, it means that something is wrong with the update. Not necessarily "very seriously wrong", though I'm pretty sure that if there was a typo introduced by the update, nobody would care to give it a negative vote. By the way, unless 47 more testers give negative karma, you can still push this to stable.

Thank you, thank you, thank you (for reminding me that I can disable dnf plugins)! Could you or csnyder or someone else please add that information somewhere visible?

I'm stopping here for tonight, because it looks like I'm getting dumber by the minute. You can add a caveat with the info about disabling the plugin in the description of this update…

Thanks Alex - apology accepted. No hard feelings.

This update literally got hosed (Bodhi called it obsolete) with the toolbox-0.0.99.5-1.fc39 build losing all its tags when the third negative karma came in. I had to do jump through various hoops to undo all that. That's not fun when right before the holidays.

When I restored it, I made sure to bump the negative karma threshold really high to 50 to avoid this. That's why you see the 47 figure.

I think what I will do in the new year is to flip the defaults of DNF's subscription-manager plugin to have it disabled by default unless there's some real problem with doing that.

That sounds like a solid plan forward. Is there a file somewhere, the existence of which could be the basis for a conditional to enable the plugin or not? Restful holidays and a happy new year!

Oops! I didn't expect python3-dnf to contain %{_bindir}/dnf-3 and %{_bindir}/dnf4. That's definitely a big problem for Fedora Silverblue.

Secondly, it looks like disabling subscription-manager's DNF plugin on Fedora hosts prevents it from upgrading UBI containers to RHEL.

Anyway, ending up with DNF executables on Silverblue is definitely a big problem. I will submit another build to drop the weak dependency on subscription-manager.