On Tue, Oct 17, 2017 at 9:19 AM Martin Pitt <martin@piware.de> wrote:
Hello all,

Stef Walter [2017-10-17 11:48 +0200]:
> This is a distro specific packaging/dependency bug and not a bug in Cockpit.
> Stephen, should we file a Fedora bug about this? Any ideas which component?

There is a (slightly political) decision to make first. Based on that, there
are different solutions:

 (1) If the *intention* is that Fedora Server should have NM by default, then
     this should be added do the explicit list of "top-level packages" that the
     OS installer image is built from.

This is already done. The Fedora Server Edition environment group includes both the @headless-management and @networkmanager-submodules package groups. Additionally, the fedora-release-server package explicitly Requires: NetworkManager. (So if you remove it, the system stops reporting itself as being Server Edition and becomes unbranded Fedora).

     After installing all packages, the installer should mark all these
     "top-level" packages as manually installed (dnf mark install), so that
     they don't suffer from this automatic cleanup. (This is what the
     Debian/Ubuntu installer does, with "apt-mark").


  (2) If the intention is that Fedora Server should by default manage its
      networking with something else (networkd, or the old sysconfig scripts
      or whatnot), as many people don't like NM on their server, then it
      shouldn't install cockpit-networkmanager by default either. In that case
      we should lower the recommends from the "cockpit" metapackage to

Server Edition very explicitly considers Network Manager to be the official network stack.

That being said, elsewhere in the thread it was reported that the original poster was using Cloud Edition, not Server Edition. This environment group does NOT pull in NetworkManager or Cockpit by default. So if Cockpit was installed manually it would have pulled NM in as a dependency solely of Cockpit.

So it's probably *correct* that NM wasn't marked as separately installed in this case. The bug then is that NM apparently became promoted to the main network stack somehow, such that its removal caused problems. I saw something about "DNS not working", but not with enough context to go on.

I think things are probably functioning as *designed* here, but the design doesn't account for unknowing actions on the part of the end-user. I have always been (and continue to be) opposed to the setting of clean_requirements_on_remove by default.