El 07/07/24 a las 18:02, Martin-Éric Racine escribió: > su 7. heinäk. 2024 klo 16.56 Daniel Gröber (d...@darkboxed.org) kirjoitti: > > On Sun, Jul 07, 2024 at 12:38:34PM +0300, Martin-Éric Racine wrote: > > > While discussing pending issues with Santiago (ifupdown's de-facto > > > maintainer), we came to the conclusion that team maintenance of just > > > one ifupdown implementation would be a better way to go than having 3 > > > different implementations of the same. > > > > Is that discussion public? What's the reasoning of that conclusion? > > Not until now.
Thanks Martin-Éric for initiating the discussion, and Daniel for making it public. The topic should have had to be discussed openly at some point. > Basically, there's pending issues involving ifupdown and DHCP clients > that I've randomly discussed with Santiago. > > One of these is to swap the default DHCP client (isc-dhcp-client > i.e.dhclient to dhcpcd-base). > > Another is the plethora of unresolved issues with ifupdown and > Santiago's limited time to devote to its maintenance. He initially > asked if I'd be interested in maintaining it, then pondered whether > having 3 implementations even makes sense to begin with. I suggested > contacting the maintainers of all 3 implementation to discuss this. [...] > > > This e-mail is meant to launch discussion over which of the 3 > > > implementations would be the best candidate for this. > > > > 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, 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... > > 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. > > 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. > > DHCP on the other hand affects us all. I'd be very much on board with > > pooling resources around that. > > dhcpcd covers both v4 and v6 transparently and also provides IPv6-PD. > The current plan is to swap ifupdown's default to prefer it to > dhclient and to swap Priority between dhclient and dhcpcd-base. And we would need to the change in the override first, isn't it? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038882 Cheers, -- Santiago
signature.asc
Description: PGP signature
