Hi Santiago, On Mon, Jul 08, 2024 at 12:23:16PM -0300, Santiago Ruano Rincón wrote: > > > Santiago, how do you feel about ifupdown's future maintainability and > > > feature development? I honestly never looked into why people started > > > writing ifupdown replacements. I had my own gripes with it so I never > > > questioned it but I'm happy to hear why we should all rally around it. > > > > I've long wondered how we ended up with so many implementations. Team > > maintenance of just one implementation would make more sense. > > > > > For me the reason to work on ifupdown-ng is that it has a better core > > > design, clean&modern code, an active upstream community, a ***test > > > suite*** > > I fully acknowledge this. After trying to fix some of the ifupdown bugs > but hitting some design issues,
Can you elaborate on that point? What are the sort of issues you run into with the traditional ifupdown design and/or it's maintenance. > I think it makes more sense to focus all > the efforts in just one of the implementations, and since ifupdown-ng > has all the above mentioned advantages, I'd would be in favor of > replacing ifupdown by ifupdown-ng... Good to hear. From the looks of the BTS page I feel like part of the burdon of maintaining ifupdown is that people just default to reporting any networking issues there, is that something you see a lot? Perhaps we should have a debian-networking mailing list as Maintainer to be able to load-share the user-support better? > > > and the potential to fully replace ifupdown without breaking anyone's > > > system doing it. Full compatibility is not there yet. I'm working on it, > > > see [1] but I'm optimistic so far. > > > > > > [1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/247 > > > > Noted. > > ... but it would be *great* to make ifupdown-ng a drop-in replacement > first. Naturally. It is pretty close though. The remaining issues I know about are documented in the GH issue: the locking protocol is sligtly suboptimal (and more importantly for interop: different), ifstate file is separate and interface renaming ("rename" statanza) isn't supported. I didn't even know that last one existed, does anyone use those? If you're on-board with transitioning to -ng that should make the ifstate compat pretty easy since we can freeze the old format and behaviour. I haven't thrown -ng at a large legacy setup in anger yet (since I don't have any), but for regular desktop usage with some mildly custom stuff in /etc/network/interfaces I hardly notice which ifupdown* I have installed. Note: For testing you have to keep in mind to (tranditional) ifdown the ifaces you want to test first since the ifstate is still disjoint currently. > > > From where I'm sitting ifupdown2 is completely out of the question as > > > *the* Debian ifupdown since it doesn't even support *basic* IPv6 > > > use-cases like DHCPv6. Upstream community seems nonexistant since > > > this is software by a corp for a corp where community building was > > > probably never the goal. Admittedly I didn't look very hard, this is > > > just my impression currently. > > > > That's also my impression. > > and the python dependency makes me consider ifupdown2 as not an option. Right, glad we're on the same page here. --Daniel
signature.asc
Description: PGP signature
