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. > > > Not quite true, vlan support is now internal AFAIK, or at least I haven't > > > installed `vlan` in ages and things seem to work :) > > > > I said ifupdown, not ifupdown-ng. > > I was talking about *ifupdown*. Sorry for not being clear. See `VLAN > INTERFACES` interfaces.5 and/or grep for `type vlan` in > ifudown/link.defn. Interesting. Thanks for the heads up. Yet we still have this package: vlan - ifupdown integration for vlan configuration > > > > 4) That systemd unit generation blissfully ignores anything else that > > > > physical interfaces in /etc/network/interfaces which introduces yet > > > > more reproducibility problems. > > > > > > Not sure what you're talking about here? > > > > ifupdown has helpers that dynamically generate systemd service units > > upon bootup. It only generates them for en* and wl* interfaces, which > > are then started at random according to systemd preferences. Later in > > the boot process, a generic networking.service unit is run to bring up > > everything else found in /etc/network/interfaces e.g. vlan, bridges. > > I'm not aware of any such component. I don't see any systemd-*-generators > packaged as part of ifupdown. systemd-network-generator.8, part of systemd > mind you, doesn't look relevant. See ifupdown-pre.service and ifup@.service shipping with ifupdown. > On Thu, Jul 11, 2024 at 08:13:38AM +0200, Marc Haber wrote: > > I eventually decided to drop that easy-of-use for networkd, lowering my > > workload significantly. > > Since we're still lacking technical arguments for why ifupdown is > problematic, could you elaborate on how it was causing an increase in your > workload? I'd really like to hear this as well. Similarly, I have yet to hear any compelling reason for dropping all DHCP clients and ifupdown implementations from the default install and instead using networkd or for using netplan instead of ifupdown. Martin-Éric
