Pull request:
https://pagure.io/fedora-comps/pull-request/881

Why not just add this as a recommends to the toolbox package?

Why not just add this as a recommends to the toolbox package?

This is what I would do too. It's not really something that we would want in Workstation for any reason other than toolbx wants it.

Why not just add this as a recommends to the toolbox package?

It works with any UBI container created by Podman, so if you want to go that route then we should probably add it to the podman RPM.

I think it also boils down to whether we want to advertise easy consumption of the Red Hat Developer Program as a Fedora Workstation feature or not. If we do, then I think subscription-manager should reside in comps so that we can ensure that it doesn't fall off because of some inadvertent changes in the RPM dependencies.

I learnt that @kalev is working on bringing the subscription UI from RHEL's Settings to Fedora 39. If or once that happens, it will have a run-time dependency on subscription-manager.

I would consider a Settings UI as enough advertising, because it would no longer be such an easter egg.

In case that doesn't happen for whatever reason, then I think this is still relevant.

If we just add the subscription manager UI as is, I suspect that a lot of users won't know why it is there or what it is for.

Also, the subscription manager UI is designed with the assumption that it is part of a RHEL install, so we'd need to check that it makes sense

1. in a Fedora context, and
2. when the main (only?) type of subscription is a RH developer program account.

In other words, I think that this would require some changes to the subscription manager UI - at least the text.

when the main (only?) type of subscription is a RH developer program account

I expect paid subscription accounts (like those of Red Hat customers) to work just the same as the gratis, self-supported Red Hat Developer Program accounts. However, the latter is more important in the context of Fedora, and that's what I primarily test against.

I learnt that @kalev is working on bringing the subscription UI from RHEL's Settings to Fedora 39. If or once that happens, it will have a run-time dependency on subscription-manager.

What I've been working on is upstreaming the RHEL subscription manager patches so that we can make sure they keep building (through eln), but enabling the Settings UI for Fedora is something completely different and needs separate discussion.

Why not just add this as a recommends to the toolbox package?

These days toolbox is also part of Fedora CoreOS' OSTree image, and Fedora CoreOS prefers not to have Python in there. subscription-manager is written in Python. So, that's one thing to watch out for.

/cc @dustymabe @siosm

Fedora CoreOS does not pull in Recommends so I don't think this would be an issue.

Adding it as a Recommend or as part of the workstation comps would add it to all rpm-ostree based desktop variants as they all include toolbox / a sub set of this comps group.

While I would like this to be added by default, I think the question here is more about adding support by default for "third party" "commercial" offering in Fedora. Is there a precedent for that? What if another company made a similar offer, would we include it?

While I would like this to be added by default, I think the question here is more about adding support by default for "third party" "commercial" offering in Fedora. Is there a precedent for that? What if another company made a similar offer, would we include it?

I guess it should work automatically, so long as they use subscription-manager. :D

The precedent would be established that if someone else were to request their tooling to be shipped in Fedora by default, we would necessarily grant it.

For example, if someone wanted SUSEConnect to be shipped in Fedora and working with toolbox for SLE images, then there would be no ground to stand on to deny it if we're shipping subscription-manager.

The precedent would be established that if someone else were to request their tooling to be shipped in Fedora by default, we would necessarily grant it.

For example, if someone wanted SUSEConnect to be shipped in Fedora and working with toolbox for SLE images, then there would be no ground to stand on to deny it if we're shipping subscription-manager.

If someone wanted to package SUSEConnect in Fedora they are of course free to do so, but I disagree that including subscription manager in the Fedora Workstation default creates some kind of precedent. Fedora Workstation is by design an opinionated operating system and if we feel that including subscription manager is a benefit to our users we can do so without any automatic requirement that we ship other pieces of software by default. I mean shipping GNOME in Fedora Workstation doesn't create a moral imperative to ship XFCE in Fedora Workstation as an example.

The precedent would be established that if someone else were to request their tooling to be shipped in Fedora by default, we would necessarily grant it.

For example, if someone wanted SUSEConnect to be shipped in Fedora and working with toolbox for SLE images, then there would be no ground to stand on to deny it if we're shipping subscription-manager.

If someone wanted to package SUSEConnect in Fedora they are of course free to do so, but I disagree that including subscription manager in the Fedora Workstation default creates some kind of precedent. Fedora Workstation is by design an opinionated operating system and if we feel that including subscription manager is a benefit to our users we can do so without any automatic requirement that we ship other pieces of software by default. I mean shipping GNOME in Fedora Workstation doesn't create a moral imperative to ship XFCE in Fedora Workstation as an example.

Those are very unlike scenarios. It's all about the rationale for doing so. You're doing it for enabling RHEL containers on Fedora because UBI is not sufficient for real use. By the same token, making it so people can use toolboxes of other distros is entirely in scope for making Fedora Workstation a good "developer platform" if you consider containerized workflows for development in scope.

The imperative that Workstation is a GNOME-based platform means that including Xfce or KDE Plasma gets harder unless there's a sufficient argument that KDE Plasma makes for so much of a better experience than GNOME that we should change. That's not what we're talking about here.

It looks like https://pagure.io/fedora-comps/pull-request/881 was merged (this adds subscription-manager to comps in F40). I think I agree that it would be better for toolbx to depend on subscription-manager, instead.

Also, just to make sure we're on the same page - since toolbx is cli-only, I think that it only makes sense to include the subscription-manager cli at this point. Having a gui would be good if there are more places that RH developer accounts are integrated, but that's something for further down the road.

The precedent would be established that if someone else were to request their tooling to be shipped in Fedora by default, we would necessarily grant it.

For example, if someone wanted SUSEConnect to be shipped in Fedora and working with toolbox for SLE images, then there would be no ground to stand on to deny it if we're shipping subscription-manager.

If someone wanted to package SUSEConnect in Fedora they are of course free to do so, but I disagree that including subscription manager in the Fedora Workstation default creates some kind of precedent. Fedora Workstation is by design an opinionated operating system and if we feel that including subscription manager is a benefit to our users we can do so without any automatic requirement that we ship other pieces of software by default. I mean shipping GNOME in Fedora Workstation doesn't create a moral imperative to ship XFCE in Fedora Workstation as an example.

Those are very unlike scenarios. It's all about the rationale for doing so. You're doing it for enabling RHEL containers on Fedora because UBI is not sufficient for real use. By the same token, making it so people can use toolboxes of other distros is entirely in scope for making Fedora Workstation a good "developer platform" if you consider containerized workflows for development in scope.

The imperative that Workstation is a GNOME-based platform means that including Xfce or KDE Plasma gets harder unless there's a sufficient argument that KDE Plasma makes for so much of a better experience than GNOME that we should change. That's not what we're talking about here.

I don't think we significantly disagree. I think the Workstation Working Group has the ability to include whatever software they think will advance the agenda of Fedora Workstation, but I don't believe including any software creates an entitlement for any other software to be included.

I believe that the case for excluding it would be a much harder sell if someone wanted to add it. That's the point I'm making. We cannot default to "no" since we accepted it for the RHEL case.

I believe that the case for excluding it would be a much harder sell if someone wanted to add it. That's the point I'm making. We cannot default to "no" since we accepted it for the RHEL case.

Do we default to 'no' for anything? I mean the WG should evaluate every suggestion and request that comes it way. But at the end of the day nobody can force the WG to include anything in the Workstation default image.

Fedora isn't closely associated with SUSE and having SUSEConnect installed by default would seem weird, even if it was able to unlock similar functionality. This is starting to feel a little too hypothetical. It's not like anybody is going to seriously propose shipping Fedora Workstation with SUSEConnect preinstalled.

My $0.02: having subscription-manager installed by default as a recommended dependency of toolbx seems sensible to me. But a control panel with UI exposing subscription-manager would be too niche.

It looks like https://pagure.io/fedora-comps/pull-request/881 was merged (this adds subscription-manager to comps in F40). I think I agree that it would be better for toolbx to depend on subscription-manager, instead.

This SUSEConnect angle might be illustrating what I tried to say before.

Toolbx currently doesn't have any built-in support for the SUSE family. However, if it does so in future, and someone comes up with a desire to put a Recommends: in the toolbox RPM, which isn't directly controlled by the Workstation Working Group, then it will be awkward to refuse that, because it would be following in the foot steps of Recommends: subscription-manager.

Instead, if subscription-manager is pulled in through comps, which is directly controlled by the WG, then there's room to make that distinction between RHEL and SUSE based on non-technical arguments like project direction and priorities and such.

It's not like anybody is going to seriously propose shipping Fedora Workstation with SUSEConnect preinstalled.

You never know. :)

Back when we added the Fedora provider to GNOME Online Accounts, there were some Fedora old-timers who wanted to have a similar integration with Ubuntu's accounts system by default in Fedora Workstation. I was told that there's some overlap between Fedora and Ubuntu contributors and it would help with that. Luckily, nobody stepped up to write the code and it died down.

That barrier might not be too high in this particular case with OCI containers and subscriptions.

This SUSEConnect angle might be illustrating what I tried to say before.

Toolbx currently doesn't have any built-in support for the SUSE family. However, if it does so in future, and someone comes up with a desire to put a Recommends: in the toolbox RPM, which isn't directly controlled by the Workstation Working Group, then it will be awkward to refuse that, because it would be following in the foot steps of Recommends: subscription-manager.

I think that's a feature, not a bug ;)

I would say that if Toolbx functionality is enhanced by installing a tool for another distro (subscription-manager, SUSEConnect, whatever else), and that functionality is expected to be useful for our users, we should seriously consider pulling it in. This is never absolute, we should also consider for example: is the tool pulling in a huge dependency chain (e.g. something in Perl could be evaluated differently to something in Python, which itself could be evaluated differently to something stand-alone), does the tool work well and smoothly, is the other distro main-stream or fringe (e.g. I don't think we should evaluate hypothetical support for Debian/kFreeBSD or RebeccaBlackOS the same as support for RHEL, Ubuntu or SUSE).

I recently started working on adding support for RHEL and RHEL UBI to mkosi (https://src.fedoraproject.org/rpms/mkosi). The situation is somewhat similar: subscription-manager is likely to be necessary, and I expect to add Recommends: subscription-manager to the package when that is useful.

Instead, if subscription-manager is pulled in through comps, which is directly controlled by the WG, then there's room to make that distinction between RHEL and SUSE based on non-technical arguments like project direction and priorities and such.

That doesn't sound like the right approach. I expect that only some minority of Workstation users use podman or toolbx, which means that pulling in subscription-manager would be wasted for most users. Adding the dependency as Recommends to the tools which would make use of it is much more targeted and much more useful. Also, non-Workstatation users of podman or toolbx are just as likely to want to use subscription-manager, so adding the dependency to the packages make much more sense.

tl;dr: I think it's best to close this ticket, and just add Recommends: subscription-manager to toolbx, podman, systemd-container, mkosi, and possibly libvirt-something, etc., on a case-by-case basis.

tl;dr: I think it's best to close this ticket, and just add Recommends: subscription-manager to toolbx, podman, systemd-container, mkosi, and possibly libvirt-something, etc., on a case-by-case basis.

This makes sense to me. Feel free to use Recommends: wherever it makes sense to do so!

The existing subscription-manager cli is not going to provide a good experience on Fedora, and I don't think we should be expecting people to use it.

First, it's an advanced admin tool which is designed for use with RHEL. There's far too much complexity for someone who wants to quickly register their system. (Of even the "primary" commands, less than half are useful for someone wanting to use a Red Hat developer account on Fedora.)

Second, subscription-manager has to be run as root, which is something that we don't set up out of the box.

The existing subscription-manager cli is not going to provide a good experience on Fedora, and I don't think we should be expecting people to use it.
Second, subscription-manager has to be run as root, which is something that we don't set up out of the box.

Yes. But that's the tool that is provided to register RHEL instances, not something under our control from Fedora side. I would expect that RH will improve subscription-manager if feedback is provided.

I would expect that RH will improve subscription-manager if feedback is provided.

It's not a matter of improving the existing subscription-manager CLI, but rather about providing an experience that makes sense in a Fedora context. So instead of making generic improvements, I'd be looking to provide a dedicated CLI specifically for Fedora.

This would essentially be a slimmed down version of the subscription-manager CLI with just the things that a developer on Fedora needs, perhaps with a more guided experience so people don't need to learn any arguments.

Hmm, maybe. But wouldn't it be better to just do some changes in subscription-manager? The command can have additional functionality that is simply not used in the default Fedora workflow. Having a completely separate tool that only serves a narrow case means that there's two codebases to manage, and it's harder to switch to the "big" tool when necessary.

Anyway, we probably shouldn't discuss this here.

FYI, DNF already uses librhsm instead of the whole subscription-manager in some cases, which might be a better way to go for this too...

It looks like this won't be as trivial as adding Recommends: subscription-manager to toolbox.spec.

The subscription-manager package ships a DNF plugin that generates 1 to 3 lines of extra spew during many common DNF commands. Some users don’t like this. It might need code changes in subscription-manager because simple configuration changes to suppress the DNF plugin prevent the UBI containers from getting upgraded to RHEL.

Secondly, it pulls in /usr/bin/dnf-3 and /usr/bin/dnf4 through python3-dnf. This is a problem on Fedora Silverblue, because we don’t want these on OSTree based operating systems. This is related to the above problem because disabling the DNF plugin at compile time doesn’t work.

So, if we want to make it easier to have gratis, self-supported Red Hat Enterprise Linux containers on Fedora Workstation and Silverblue, then it might be worth tracking as a top-level work item.

Let's discuss this at the January 23 Workstation WG meeting.

Can subscription-manager be in the rhel toolbox container itself?

It seems strange/confusing to have in the host Fedora system.

We are going to decline to pull in subscription-manager via comps.

toolbox is fine to depend on it if desired, provided that (a) subscription-manager does not depend on any version of dnf, and (b) in default configuration, it does not add extra output when running dnf.

in default configuration

(By which I mean: when the user has not configured anything via subscription-manager)

I am surprised that this issue was closed as WONTFIX.

We are going to decline to pull in subscription-manager via comps.

This issue is about making subscription-manager available in Fedora. Not necessary about pulling it in through comps.

I reopened this issue because there are bigger problems than just deciding how to list subscription-manager as a dependency. Solving those problems need to be tracked somewhere.

This issue is about making subscription-manager available in Fedora. Not necessary about pulling it in through comps.

The issue title is "Include subscription-manager by default from Fedora 40 ". Does it need to be updated?

This issue is about making subscription-manager available in Fedora. Not necessary about pulling it in through comps.

The issue title is "Include subscription-manager by default from Fedora 40 ".

And it continues:
"... to make it easier to have gratis, self-supported Red Hat Enterprise Linux containers on Fedora."

Moreover, toolbox is included by default in Fedora Silverblue and Workstation.

Does it need to be updated?

Please feel free to update it or suggest a change, if you think it will be better. I don't have any thoughts as to what it would be.

Why not just add this as a recommends to the toolbox package?

By the way, some folks have pointed out that once a weak dependency is removed, it gets pulled in with the next round of DNF updates.

I know of:
https://bugzilla.redhat.com/show_bug.cgi?id=1699672
https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect

... and from those, I get the idea that a removed weak dependency will stay removed. Is that not the case?

Can subscription-manager be in the rhel toolbox container itself?

In theory, yes, but it doesn't work today.

Trying to use subscription-manager today inside a Toolbx container will lead to some permission errors coming from /proc/1/environ, and it won't work. That's because /proc is bind mounted from the host, and since Toolbx containers have no PID namespace, it's referring to the host's /proc/1/environ, which only the host's root can access.

It seems strange/confusing to have in the host Fedora system.

It depends on the user experience we want. Separately registering each container might get tiring if someone creates several of those regularly. eg., someone might also want to do this with regular Podman containers, which are likely deleted and created more often.

It seems strange/confusing to have in the host Fedora system.

It depends on the user experience we want. Separately registering each container might get tiring if someone creates several of those regularly. eg., someone might also want to do this with regular Podman containers, which are likely deleted and created more often.

Seconded. I think it would just be so much more versatile if we could install subscription-manager anywhere/everywhere, and have it DTRT depending on the environment. It shouldn't be so hard to make it smart enough to not complain about the subscription if the host is Fedora and fix dependencies so the package does not unconditionally pull in stuff that people don't want.

If we do that, then the whole discussion where to install it has very low stakes. After all, it's just a tiny python script.

I am surprised that this issue was closed as WONTFIX.

Hi, it's actually closed as "Fixed" which just means "Working Group has agreed on a policy." Your proposal is approved. I think there is nothing further that the Working Group needs to consider at this time, but feel free to reopen if you need more from us.

I understand you want an open issue somewhere to track your progress, but this is probably not the best issue tracker for that. I understand the primary problem now is figuring out how to make subscription-manager not depend on dnf. We're unlikely to be able to help with that.

By the way, some folks have pointed out that once a weak dependency is removed, it gets pulled in with the next round of DNF updates.

That problem was fixed by the exclude from weak autodetect change that you linked to.

Cool! Thanks for clarifying that, @catanzaro