networkmanager (all versions) currently depends on net-dns/openresolv. As of version 239, systemd now supports a resolvconf-compatible interface, and so a virtual has been created to support both (bug 659220). If the resolvconf interface is the only required component of openresolv, please update the dependency to virtual/resolvconf. If there are other required components then feel free to close this bug. Thanks! 5:)
NetworkManager already has an integration with systemd-resolved via D-BUS. It would not make much sense for it to use the /sbin/resolveconf interface. I do not think changing the dependency to virtual/resolvconf makes sense in this case.
Fair point. At the moment, however, systemd[resolvconf] and NetworkManager[resolvconf] are mutually incompatible, because one installs openresolv and the other blocks on installation of openresolv. This means that people who have previously turned on resolvconf, for whatever reason, are prevented from upgrading systemd because it now includes a resolvconf flag which causes blocks. I don't know how best to fix this, but at the moment it's anything but clear why the block occurs, and that one or the other of the "resolvconf" flags needs turning off depending on whether you're using systemd to resolve or not. The simplest immediate solution would be to alter the USE flag description to make it clearer that it should be off when using systemd as your main resolver. The other solutions I can think of all face the difficulty of having to know whether someone is actually using it for their DNS resolution or not. If you still believe this to be invalid, mark it as such and I won't reopen it again, but I'd prefer to have somewhere (like this bug) that people can find to answer their question of why the two block each other and how best to fix that conflict.
> I'd prefer to have somewhere (like this bug) that people can find to answer their question of why the two block each other and how best to fix that conflict. So you want to keep this bug open perpetually? That makes no sense. I don't really see anything wrong with the current state of affairs: networkmanger[resolvconf] is disabled by default, so there's no conflict out of the box. It's hard to tell how many people have enabled networkmanager[resolvconf]; if you think the number is significant, you could write a news item to broadcast a warning to people.
(In reply to Mike Gilbert from comment #3) > > I'd prefer to have somewhere (like this bug) that people can find to answer their question of why the two block each other and how best to fix that conflict. > > So you want to keep this bug open perpetually? That makes no sense. > > I don't really see anything wrong with the current state of affairs: > networkmanger[resolvconf] is disabled by default, so there's no conflict out > of the box. > > It's hard to tell how many people have enabled networkmanager[resolvconf]; > if you think the number is significant, you could write a news item to > broadcast a warning to people. How about we ignore USE=resolvconf in networkmanager if USE=systemd is set? As is, this is a pretty confusing blocker and all you need to do is set USE="resolvconf systemd" in make.conf to trigger it. I added resolvconf to my make.conf because vpnc broke without it. Please don't argue that this is acceptable because it doesn't happen 'out of the box'. That's just a waste of time.
With systemd-resolved enabled, networkmanager does not update /etc/resolv.conf unless it is built with USE=resolvconf. So I think floppym is wrong and we should do as ikelos suggests and change the dependency to resolvconf? ( virtual/resolvconf )
(In reply to Matt Turner from comment #5) > With systemd-resolved enabled, networkmanager does not update > /etc/resolv.conf unless it is built with USE=resolvconf. I should clarify that I build networkmanager with USE=resolvconf and --nodeps to avoid it attempting to install openresolv.
(In reply to Matt Turner from comment #5) > With systemd-resolved enabled, networkmanager does not update > /etc/resolv.conf unless it is built with USE=resolvconf. To utilize systemd-resolved, /etc/resolv.conf should be a symlink to /run/systemd/resolve/resolv.conf or /run/systemd/resolve/stub-resolv.conf. systemd-resolved should updated these as-needed in response to D-BUS messages from the NetworkManager plugin. There should be no need to call /sbin/resolvconf. If the sysadmin has chosen to bypass systemd-resolved by making /etc/resolv.conf a regular file, then the /sbin/resolvconf binary would be useful for NetworkManager, but only if it is provided by openresolv.
I get the following logged to the journal when running net-misc/networkmanager[resolvconf] with sys-apps/systemd[resolvconf]. Nov 15 00:48:20 sayori NetworkManager[2136]: <info> [1542260900.8398] dns-mgr: Writing DNS information to /sbin/resolvconf Nov 15 00:48:20 sayori NetworkManager[2136]: Unknown interface 'NetworkManager': No such device Nov 15 00:48:20 sayori NetworkManager[2136]: <warn> [1542260900.8478] dns-mgr: resolvconf failed with status 256 Nov 15 00:48:20 sayori NetworkManager[2136]: <warn> [1542260900.8481] dns-mgr: could not commit DNS changes: resolvconf failed with status 256 NetworkManager calls "/sbin/resolvconf -a NetworkManager", which systemd's resolvconf does not like. It expects to see an interface name, not some arbitrary string like "NetworkManager". So really, net-misc/networkmanager[resolvconf] just cannot work without openresolv.
(In reply to Matt Turner from comment #4) > How about we ignore USE=resolvconf in networkmanager if USE=systemd is set? Nope, that would be an abuse of the 'systemd' USE flag. It controls features that require libsystemd to work; systemd-resolved support is provided via a dbus interface, and does not require libsystemd. Also, it is perfectly acceptable for a user to run systemd and not enable systemd-resolved.In this case, /sbin/resolvconf provided by sys-apps/systemd[resolvconf] is useless, and they might find net-dns/openresolv very useful for managing /etc/resolv.conf. There is no magic way to resolve this via USE flags or virtual packages because the "correct" configuration depends heavily on runtime configuration. The default USE flags on NetworkManager and systemd probably cover the most common use case.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4705062eb6847dce48e241f8ef286a3e9626a120 commit 4705062eb6847dce48e241f8ef286a3e9626a120 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2018-11-15 06:41:53 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2018-11-15 06:41:53 +0000 net-misc/networkmanager: add hints to resolvconf USE description Bug: https://bugs.gentoo.org/669246 Package-Manager: Portage-2.3.51_p9, Repoman-2.3.12 Signed-off-by: Mike Gilbert <floppym@gentoo.org> net-misc/networkmanager/metadata.xml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
Thanks for updating the USE description, Mike. 5:) Please also see the following about using d-bus even when resolvconf has been selected, because the symlink points to a specific location. https://bugzilla.gnome.org/show_bug.cgi?id=796758 They already have this capability, but it requires that people make the symlink to the right location (/run rather than /var/run), which is further documentation needed somewhere on the Gentoo side until we get rid of that symlink. As such, as long as the symlink is in the right place, systemd *could* be installed with virtual/resolvconf, but it would require that systemd's resolver be configured correctly which is a long-shot and probably not worth the effort now the USE flag is clearer.
(In reply to Mike Auty from comment #11) > They already have this capability, but it requires that people make the > symlink to the right location (/run rather than /var/run), which is further > documentation needed somewhere on the Gentoo side until we get rid of that > symlink. The /var/run symlink is mainly there for compatibility with older programs that write pidfiles or create UNIX sockets there. There are no plans to get rid of the /var/run symlink for the foresable future. I am not aware of any documentation that would have lead you to create a symlink to /var/run/systemd/. There is a wiki page on that documents various options for resolv.conf. https://wiki.gentoo.org/wiki/Resolv.conf
