El 09/07/24 a las 11:25, Daniel Gröber escribió: > 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.
For example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804396. Fixing it is not trivial. > > 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? No, not really. > Perhaps we should have a debian-networking mailing list as Maintainer to be > able to load-share the user-support better? I'd happy with that! > > > > 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? Yes, I am aware there are users of the rename stanza. > 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. ACK. [snip] Cheers, -- Santiago
signature.asc
Description: PGP signature
