Martin-Éric Racine wrote: > la 13. heinäk. 2024 klo 2.02 Daniel Gröber (d...@darkboxed.org) kirjoitti: > > On Thu, Jul 11, 2024 at 12:57:52PM +0300, Martin-Éric Racine wrote: > > What I'd like to know is why is removing all traces of ifupdown* from a > > minimal Debian install important? Clearly Desktop/Cloud image maintainers > > think a different tool is more well suited for their users. That's fine. > > > > The question is: What problems does ifupdown* cause that make its removal > > from the base system worthwhile? > > I haven't seen any answer to this one either.
Leaving aside the questions of "what use cases does ifupdown not handle" (which it sounds like folks are generally acknowledging the existence of), the question of "why is it important to remove ifupdown and its configuration from the system" has a fairly simple answer: because different network tools trying to poke at the same network devices, *or* network tools working around each other to carefully *not* poke at the same network devices, causes problems and conflicts and user surprises, and should be treated as an unusual non-default configuration rather than a common one. It is possible to carefully configure a system such that ifupdown handles one set of interfaces while NetworkManager or systemd-networkd handles a disjoint set, but there's little to no benefit to doing so for most users: once you're using one of those, *most* users will want to let that tool handle a *complete* picture of the attached network devices in order to set up the configuration the user wants. NetworkManager has a dedicated plugin with a pile of logic to attempt to detect if an interface lives in /etc/network/interfaces and treat it as "unmanaged". In practice, however, *most* desktop users running NetworkManager will get a suboptimal experience if they have any interfaces configured in /e/n/i, compared to the experience they get if NetworkManager manages all interfaces. This is why, for instance, debian-installer already has logic to check if the user is installing a desktop system, and in that case, copy the network configuration over to NetworkManager if needed and remove it from /etc/network/interfaces. Given that, I would suggest in general that it makes sense for the installer to treat network management tools as mutually exclusive rather than keeping more than one tool installed: e.g. if installing the desktop task install and configure NetworkManager, else install and configure something else. That doesn't *stop* people from installing whatever they want, it just makes the common case have just one tool and one path for the user to deal with. If a user with an unusual use case wants to install more than one network management tool and configure them to carefully manage disjoint sets of interfaces, they can absolutely do that; I'm not suggesting that the tools should have Conflicts with each other. But if there were some kind of "Recommends-Conflict" for "packages that would *not* be found together except in unusual installations", it'd make sense for network management tools to Recommends-Conflict each other. And in the meantime, it makes sense for the installer to treat them as effectively mutually exclusive so that the user's installed system ends up with at most one of them. - Josh Triplett
