On Sat, Sep 5, 2026 at 11:31 AM Martin-Éric Racine < [email protected]> wrote:
> > That's why I'd really love for dhcpcd to eventually become capable of > setting up bridges and vlans. Once it can do that, ditching ifupdown > and using dhcpcd.conf instead of /etc/network/interfaces would make > sense. Even better would be to teach dhcpcd to read and use > /etc/network/interfaces as-is to configure multiple interfaces. Since > the file is generated by ifupdown at install time, it's never deleted, > even after purging ifupdown. This would provide the smoothest > transition from ifupdown+dhcpd to dhcpcd in manager mode. Debian could > just deprecate ifupdown and install dhcpcd in manager mode from that > point on. At that point, you may as well rename it systemd-dhcpcd. ;-) In all seriousness, monolithic consolidation is not the ideal end state. IMO, the right approach is to have black-box interfaces around discrete functions that can be implemented differently while enabling predictable behaviors across those functions. For example, router advertisements don't necessarily need to be multicast by the DHCP client, but the DHCP client *does* need to be able to inform the RA daemon about the prefixes it has delegated to each interface and which in turn need to be advertised to clients on those segments. This is an inherently more difficult pattern to implement, but the end state is one that is a lot more resilient, as well as more customizable where users need greater control. But now we're into philosophy, so probably best to relegate this one to bar talk. ;-) Kyle
