ti 9. heinäk. 2024 klo 15.13 Daniel Gröber (d...@darkboxed.org) kirjoitti: > Users may choose to opt-in to the more declarative "use" stanzas if they > wish and I'd expect any new upstream executors like vrf will need them > (haven't tried) but not traditional stanzas or if-*.d based extensions. > > I wish ifupdown-ng upstream hadn't chosen to introduce an additional set of > global config options in /etc/network/ifupdown-ng.conf and I am still > mulling getting rid of that somehow but so far I don't see a real problem > there.
That sort of needless additions precisely is what makes me doubt whether ifupdown-ng is the way to go. > > > Please note that the examples in the manpages are in what upstream > > > considers the "proper new way" of doing things, they don't show the legacy > > > way (also a good thing), you may have to read the code to get the full > > > picture. Do let me know if any legacy-format behavioural > > > reference-documentation is missing though. > > > > Claiming to offer a drop-in substitute all while nudging people > > towards a new paradigm is not welcome. > > If ifupdown's paradigm were working for people we wouldn't be having this > conversation. The paradigm is working. What doesn't work is how a package with such a high priority has repeatedly fallen into neglect. If people file bug reports or request enhancements, but nothing happens, a fork is unavoidable. In fairness, a few people have randomly stepped in, but clearly don't have enough time to maintain it. > How else would you move /etc/network/interfaces forward without breaking > anything? I would really like to hear what is wrong with the current format. For my perspective, the main issues with ifupdown are: 1) ifupdown doesn't handle bridges and vlans without external packages, yet it already depends upon iproute2, which provides 'ip' i.e. a command that can handle these quite nicely. 2) ifupdown doesn't include a way to handle DHCPv6-PD for all supported DHCP clients. 3) Since the introduction of systemd units, one can no longer rely on interfaces being brought up sequentially following the order in which they appear in /etc/network/interfaces. 4) That systemd unit generation blissfully ignores anything else that physical interfaces in /etc/network/interfaces which introduces yet more reproducibility problems. Martin-Éric
