Bug 1655995

Summary: no NetworkManager-config-connectivity-fedora installed by default
Product: [Fedora] Fedora Reporter: Thomas Haller <thaller>
Component: compsAssignee: Stephen Gallagher <sgallagh>
Status: ASSIGNED --- QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 31CC: dennis, jdisnard, jkeating, kellin, kevin, mboddu, pbrobinson, sgallagh, thaller, vondruch, vpavlin, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1648721    
Bug Blocks:    

Description Thomas Haller 2018-12-04 11:58:26 UTC
It seems, due to a change in fedora-release [1], rawhide no longer installs NetworkManager-config-connectivity-fedora by default.

Was this change intentional?

[1] https://src.fedoraproject.org/rpms/fedora-release/c/242d999c07eab498c7c79fd4c0dbc8ede4b9832e?branch=master


See also, https://bugzilla.redhat.com/show_bug.cgi?id=1619873#c10

Comment 1 Thomas Haller 2018-12-04 11:59:17 UTC
CC-ing Vít (who might know more details)

Comment 2 Stephen Gallagher 2018-12-04 12:01:44 UTC
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.

Comment 3 Vít Ondruch 2018-12-04 12:47:50 UTC
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.

Comment 4 Stephen Gallagher 2018-12-04 12:52:39 UTC
(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.

Comment 5 Vít Ondruch 2018-12-04 13:33:35 UTC
`Supplements` is an interesting idea.

Comment 6 Stephen Gallagher 2018-12-04 13:52:01 UTC
(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.

Comment 7 Vít Ondruch 2018-12-05 09:15:38 UTC
(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.

Comment 8 Stephen Gallagher 2018-12-05 13:26:29 UTC
(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.

Comment 9 Vít Ondruch 2018-12-05 14:06:53 UTC
(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.

Comment 10 Stephen Gallagher 2018-12-05 14:33:00 UTC
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.

Comment 11 Ben Cotton 2019-08-13 17:04:21 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 12 Ben Cotton 2019-08-13 19:39:53 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.