CC-ing Vít (who might know more details)

The change in Fedora-release was intentional. The new approach to Edition handling necessitated that we not have dependencies in the release package. I assumed this was handled by the Workstation Comps group, but it seems it might be missing from there. I’ll get that fixed today.

I don't think comps is the right place for this dependency because it is not strong enough.

Let me explain. If for example I somehow remove gedit, then it is obvious it is not on the system once I try to use it and it is obvious it should be installed. But now I don't have NetworkManager-config-connectivity-fedora on my system anymore but I can't tell the difference. Maybe the captive portal detection does not work but I have no way to really know.

I also wonder how can I get this installed back on my system, once it was removed (well I can install it manually, I know, but obviously this is not the answer I expect). Comps won't do it for me.

(In reply to Vít Ondruch from comment #3)
> I don't think comps is the right place for this dependency because it is not
> strong enough.
> 
> Let me explain. If for example I somehow remove gedit, then it is obvious it
> is not on the system once I try to use it and it is obvious it should be
> installed. But now I don't have NetworkManager-config-connectivity-fedora on
> my system anymore but I can't tell the difference. Maybe the captive portal
> detection does not work but I have no way to really know.
> 
> I also wonder how can I get this installed back on my system, once it was
> removed (well I can install it manually, I know, but obviously this is not
> the answer I expect). Comps won't do it for me.

OK, the other answer I can suggest is that we could add `Supplements: fedora-release-workstation` to the NetworkManager-config-connectivity-fedora package, so it would be installed by default if fedora-release-workstation is.

`Supplements` is an interesting idea.

(In reply to Vít Ondruch from comment #5)
> `Supplements` is an interesting idea.

Actually, I just realized that still won't work. The solver would still attempt to process that the same way as if I made it a Recommends: in fedora-release-workstation which implies ordering. So we'd get back to the same bug I was solving when I dropped this requirement in the first place.

I don't know if there's actually any better solution than to add this to the Workstation comps group. I don't think the case of "how can I get this installed back on my system, once it was removed" is a real issue, since once it's in comps it'll be part of the default install. The only way it would *disappear* is if the user removed it manually, so I would assume they'd know how to get it back if they wanted to.

(In reply to Stephen Gallagher from comment #6)
> (In reply to Vít Ondruch from comment #5)
> > `Supplements` is an interesting idea.
> 
> Actually, I just realized that still won't work. The solver would still
> attempt to process that the same way as if I made it a Recommends: in
> fedora-release-workstation which implies ordering. So we'd get back to the
> same bug I was solving when I dropped this requirement in the first place.

You have never described in detail what is the issue actually, so hard to tell. The only thing I can say that originally, it was Requires, not Recommends. And Recommends/Supplements can help break at least build time circular dependencies.

> I don't know if there's actually any better solution than to add this to the
> Workstation comps group. I don't think the case of "how can I get this
> installed back on my system, once it was removed" is a real issue, since
> once it's in comps it'll be part of the default install. The only way it
> would *disappear* is if the user removed it manually

For new installations, maybe. In my case, it was removed by "dnf autoremove", which is legit scenario IMO. It is Rawhide, yes, but I hope that won't be an excuse.

What I still don't understand whose responsibility actually is to have this package/configuration available on the system? Is it NetworkManager? Will for example "curl" somehow benefit from the captive portal detection? Or is it Workstation/Gnome responsibility to have this in place, because you have the UI to let the user interact with the captive portal login page? Is it FF? Probably not, because FF has its own logic AFAIK.

(In reply to Vít Ondruch from comment #7)
> (In reply to Stephen Gallagher from comment #6)
> > (In reply to Vít Ondruch from comment #5)
> > > `Supplements` is an interesting idea.
> > 
> > Actually, I just realized that still won't work. The solver would still
> > attempt to process that the same way as if I made it a Recommends: in
> > fedora-release-workstation which implies ordering. So we'd get back to the
> > same bug I was solving when I dropped this requirement in the first place.
> 
> You have never described in detail what is the issue actually, so hard to
> tell. The only thing I can say that originally, it was Requires, not
> Recommends. And Recommends/Supplements can help break at least build time
> circular dependencies.

Sorry, right. The original reason these were removed is because they caused loops in the installation of the system. In the F21-F28 implementation of Edition handling, all of the minimal system stuff was handled by the `fedora-release` package and then the `fedora-release-workstation` package was entirely supplementary and provided by the installed comps group. As a result, it was just ordered late in the transaction so it could depend on things like the captive portal.

However, the new F29 implementation switches the fedora-release-$EDITION to be the provider of `system-release`. Which means that it has to be dependency-clean to ensure that it can be ordered among the first packages installed on the system.

From what I understand about RPM, Recommends wouldn't actually solve this dependency as RPM would treat it the same way as Requires as long as it's present in the repository. I may be mistaken.

We've been discussing adding functionality to RPM to make this more explicit; see https://bugzilla.redhat.com/show_bug.cgi?id=1648721 for exhaustive detail. Assuming my last suggestion naming there gets implemented, I'll add in `Requires(metapackage): NetworkManager-config-connectivity-fedora` to the fedora-release-workstation package and get the complete functionality that we desired here.

(Which, to enumerate, is that the idea should be that if someone removes the NetworkManager-config-connectivity-fedora package, the result should be that the system no longer reports itself as Fedora Workstation and instead reports itself just as Fedora.)

> 
> > I don't know if there's actually any better solution than to add this to the
> > Workstation comps group. I don't think the case of "how can I get this
> > installed back on my system, once it was removed" is a real issue, since
> > once it's in comps it'll be part of the default install. The only way it
> > would *disappear* is if the user removed it manually
> 
> For new installations, maybe. In my case, it was removed by "dnf
> autoremove", which is legit scenario IMO. It is Rawhide, yes, but I hope
> that won't be an excuse.
> 

I don't think `dnf autoremove` is a legitimate scenario, no. It's not anything we advertise or document as a recommended solution (and in general if you are using it, you are taking your own life in your hands).

If this was to break on a `dnf update` or `dnf distro-upgrade`, then I'd be alarmed. If you're using `dnf autoremove` and didn't bother to check what was being removed, I think that's your own problem, sorry.

> What I still don't understand whose responsibility actually is to have this
> package/configuration available on the system? Is it NetworkManager? Will
> for example "curl" somehow benefit from the captive portal detection? Or is
> it Workstation/Gnome responsibility to have this in place, because you have
> the UI to let the user interact with the captive portal login page? Is it
> FF? Probably not, because FF has its own logic AFAIK.

It's the responsibility of the Workstation Edition, because it was determined that the captive portal detection is part of that complete experience. The *ideal* case is for it to be mandatory for Workstation Edition but not necessarily mandatory for all users of GNOME.


Anyway, until that other BZ is resolved, I think our best option here is to rely on the comps group, which I will send a patch for immediately.

(In reply to Stephen Gallagher from comment #8)
> I don't think `dnf autoremove` is a legitimate scenario, no. It's not
> anything we advertise or document as a recommended solution (and in general
> if you are using it, you are taking your own life in your hands).
> 
> If this was to break on a `dnf update` or `dnf distro-upgrade`, then I'd be
> alarmed. If you're using `dnf autoremove` and didn't bother to check what
> was being removed, I think that's your own problem, sorry.

I completely disagree with this. Autoremove is removing dependencies which are not needed anymore. It is as simple as that. It is the more prudent opposite of "dnf update" which pulls in some dependencies. In ideal world, the dependencies should be removed during the update.

NetworkManager-config-connectivity-fedora was previously required, now it is not. There is no apparent reason not to remove it. You see that I did my homework and found out that the package is removed, while your commit does not carefully describe the reasons and implications of that.

However, I agree that if it was a soft dependency and I did "dnf remove", then it would be my fault and my problem.

Actually, on the contrary, I would argue, that not using "autoremove" might render your system with old components, which will at the end prevent updates of your system.


> Anyway, until that other BZ is resolved, I think our best option here is to
> rely on the comps group, which I will send a patch for immediately.

Despite the argument above, this might be a reasonable workaround, but you should warn everybody IMO. Now it is just Rawhide problem, but it might become a problem once F30 will get stable and people start updating.

https://pagure.io/fedora-comps/pull-request/351 has been merged as a workaround. I'll keep this open to track the addition of the new `Requires(metapackage)` solution.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
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
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.