Hi Daniel,
On 20.08.24 16:25, Daniel Gröber wrote:
Hi Lukas,
CCing d-devel,
This email was intended to first gauge opinions from networking maintainers,
before pushing it out to debian-devel@l.d.o.. All the points still hold and
are fine to be public. But let me at least add the preamble and references
that you dropped from the email quotation.
--- 8< ---
On 20.08.24 12:58, Lukas Märdian wrote:
Hi network maintainers!
After our [Networking BoF] at DebConf24 in Busan I had the impression that
Santiago is primarily interested in sunsetting classic ifupdown while avoiding
to pull in any Python dependency into our base installations. Furthermore, I
had a chat with bluca, trying to find a compromise about the suggestion made
around 38:30 of the BoF recording. – He's fine with the proposal I'll be
presenting below.
From previous discussion on debian-devel@l.d.o I also deduced that Daniel is
interested in making ifupdown-ng a [drop-in replacement] for classic ifupdown,
while the ifupdown2 maintainers are not interested in pushing their tool to
become a default choice in Debian. I myself have been trying to introduce
Netplan to a broader audience, after it got adopted by our [cloud-images] and
integrated with [debian-installer].
--- 8< ---
tl;dr: I'm sorry to say I strongly oppose both removing ifupdown* in forky
as well as raising netplan to Priority: standard. To move this forward
without conflict I think we should base the default networking tool
decision on data not developer opinion.
In the end it still needs to be a developer decision, because someone needs
to do the work. Otherwise, we would be suffering the same way we did with
classic ifupdown in the past years, as it's becoming harder and harder to
maintain. We need a healthy upstream project and people willing to do the
actual maintenance work in Debian.
Can you please elaborate why you're opposed to raising "netplan-generator"
to "Priority: standard"? That's independent of keeping ifupdown-ng installed
in Forky+ and I can't find any explanation about that in your comments below.
On Tue, Aug 20, 2024 at 12:58:28PM +0200, Lukas Märdian wrote:
So I want to find a compromise involving all interested parties. If there are
no strong objections, I'd like to move forward with a proposal (and change in
priorities via ftpmasters) that is structured as follows:
* Keep ifupdown[-ng] installed (Priority: important) as a fallback and for
existing installations
- Replacing ifupdown with ifupdown-ng, if reaching a drop-in compatible
state is feasible in time for Trixie (@Daniel, what's you stance on this?)
If we can find enough testers, yes. The implementation work still to be
done is small enough.
- bluca is requesting ifupdown[-ng] to be dropped from the default
installation for Forky, which is sensible, IMO. But we also want to keep
it around for a transitioning period (in Trixie), so that people relying
on specific if-up/down.d hooks are covered and have plenty of time to
migrate to new tooling
NACK. I'm not going to do the work to get ifupdown-ng into shape for being
the default just to have it removed again that's a ridiculous ask.
That being said I realise that without Santiago's support as ifupdown
maintainer I don't have much of a procedural leg to stand on in opposing
this.
It wasn't an ask, the intention was to have it only if feasible, with acceptable
efforts. Keeping classic ifupdown maintained for a transitioning period in
Trixie
would be an option, too, IMO. That's why we started forming the new "Debian
Networking Team" after our BoF discussions in Busan, so we could bundle
resources
and help each other out with critical maintenance & have a common channel for
communications. Testing new/compat functionality in ifupdown-ng could certainly
fall into the same category where the [networking team] could provide support.
Sunsetting classic ifupdown earlier and having a drop-in compatible ifupdown-ng
would certainly be nicer, in order to reduce maintenance burden. And knowing
there
is a tool around that can be used by people relying on /etc/network/interfaces
longer term, even after it might (potentially) get dropped from the base
installation in Forky+.
* Keep sd-networkd installed (as part of the systemd package), becoming the
recommended network config tool for minimal installations
- In debootstrap/chroots and also in minimal D-I installations (without
"standard utilities"),after the [networkd enablement] MR is landed
NACK. I have a counter proposabl for this but let's focus the discussion
the the idea below first.
Yes! This was the original intention of my email. Please share your proposal
with
us, so we can discuss and find consensus. We shouldn't be holding things back,
as
after finding consensus we'll still need to implement stuff and also want to
have
some time for broad testing before Trixie releases.
I'd like to avoid drama and calling the CTTE to make a decision on our behalf,
but
rather find a compromise between us networking maintainers. So please let me
know
if this would work for you or if you have any alternative proposal(s).
Frankly I think the problem we have here is that this shouldn't be a
technical decision. We should focus on what the majority of our users
actually want not our preferences.
It is a technical decision. Utopia/Desktop maintainers made the decision to use
NetworkManager. Cloud maintainers made the decision to use Netplan. And I
actually
talked to [D-I maintainers] about this before, as I though they'd be in a good
position to make this decision – but they didn't want to. So I started reaching
out
to the networking maintainers, about finding consensus.
I propose taking an informal vote on this to gather data on networking tool
preference among DDs and the wider Debian community to settle
this. @d-devel has this been done on decisions like these beore? How should
we go about doing this? Would a GR be more appropriate?
If it turns out I'm alone in wanting Debian to retain it's identity as
Debian I will (grudingly) step aside on this matter, but in the absence of
tangible data my current view is that this is not the case and I will take
appropriate steps to protect that identity.
Learning from the infamous systemd debate and [quoting former DPL Stefano], I
don't
think a GR is an appropriate approach:
"GRs should be used for societal and policy decisions. Using GRs for *technical*
decision is stupid. We really need to stop thinking that every single member of
the
Debian project, just because he/she is a DD, has a clue on every single
technical
matter that go on in the project."
This is not a social nor political decision. It's about choosing a (very
techincal)
network stack. So I really hope we can figure it out between ourselves and avoid
involving the CTTE, or anything else that will further delay a decision for
Trixie.
Cheers,
Lukas
--- 8< ---
On 20.08.24 12:58, Lukas Märdian wrote:
Thanks for all of your input in the recent weeks!
Let's get this topic moving after so many years of being stuck.
Cheers,
Lukas
[Networking BoF]
https://debconf24.debconf.org/talks/10-past-present-and-future-of-networking-in-debian/
[drop-in replacement] https://github.com/ifupdown-ng/ifupdown-ng/issues/247
[cloud-images]
https://blog.slyon.de/2023/07/10/netplan-and-systemd-networkd-on-debian-bookworm/
[debian-installer]
https://blog.slyon.de/2024/07/30/creating-a-netplan-enabled-system-through-debian-installer/
[networkd enablement]
https://salsa.debian.org/installer-team/netcfg/-/merge_requests/11
[networking team] https://tracker.debian.org/teams/networking/
[D-I maintainers]
https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9#note_506690
