On Tue, Oct 17, 2017 at 9:19 AM Martin Pitt <martin(a)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").
Perhaps.
(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
Suggests:.
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.