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?)
- 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
* 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
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).
Hi Lukas,
CCing d-devel,
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].
tl;dr: I'm sorry to say I strongly oppose both removing ifu
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.
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:
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,
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.
Surveying the wrong set of people will lead to unusable data. Henry Ford summarized this nicely some 100 years ago, when asked about customer input
in the development of the Ford Model T automobile: "If I had asked people what they wanted, they would have said faster horses."
IMO, the data is already there in all the different (Mini-)DebConf and
email discussion over the past couple of year. If people were just happy
with /etc/network/interfaces, we wouldn't have this discussion year after year after year..
At DebConf in Busan we discussed that we should set some timeline onto ourselfes in finding consensus (some 6-8 weeks, e.g. end of September), as changing the network stack isn't a small feat and we should do it early in the cycle, so there's plenty of time to have it properly tested. So there should be at least a little sense of urgency, even if Trixie'S release
dates are not yet announced.
I'm afraid all of this will just further delay the decision making for another year/Debian release.
PS: I'm dissapointed by the fact that you keep your counter proposal secret
and are unwilling to elaborate on your strong NACK on raising Netplan's "Priority".
It's really hard for me to take it serious this way. I've researched this topic for well over a year now, discussed it with people involved and
tried to bring reasonable options to the table. Explicitly asking for any additional options, so we can refine/merge and find consesns. It almost feels like you'd be mostly interested in just delaying/blocking progress here.. :-(
Hi Lukas,
On Mon, Aug 26, 2024 at 12:19:20PM +0200, Lukas Märdian wrote:
Surveying the wrong set of people will lead to unusable data. Henry Ford
summarized this nicely some 100 years ago, when asked about customer input >> in the development of the Ford Model T automobile: "If I had asked people
what they wanted, they would have said faster horses."
You're continuing to confirm my pre-existing view that netplan infantilizes it's users as you're applying the same thinking to the entire Debian community here.
In my mind Debian is an operating system for experts (perhaps
aspiring). Treating users like they are going to hurt themselves if we
listen to them is not acceptable conduct in this community in my opinion.
IMO, the data is already there in all the different (Mini-)DebConf and
email discussion over the past couple of year. If people were just happy
with /etc/network/interfaces, we wouldn't have this discussion year after
year after year..
The "data" sources you mention are severely biased in one way or
another. You complain about unusable data above only to suggest even more obviously unusable data here. I don't find this very convincing.
I'm afraid all of this will just further delay the decision making for
another year/Debian release.
So what? So far you're the only one complaining about this. What skin do
you have in the game if we don't move forward on this other than having an obviously biased interest in having netplan be a standard?
It's really hard for me to take it serious this way. I've researched this
topic for well over a year now, discussed it with people involved and
tried to bring reasonable options to the table. Explicitly asking for any
additional options, so we can refine/merge and find consesns. It almost
feels like you'd be mostly interested in just delaying/blocking progress
here.. :-(
I promise you I'm not intentionally, but I do recognize that it may be a side-effect. Likewise I feel like you're just interested in pushing this through as quickly as possible.
Consider that for you time is an ally, being employed to work on this (AFAICT?). For the rest of us not so much. Debian is a primarily a
volunteer project. Please stop pushing for doing things faster.
On Mon, 2 Sep 2024, at 19:41, Daniel Gröber wrote:
You're continuing to confirm my pre-existing view that netplan infantilizes it's users as you're applying the same thinking to the entire Debian community here.
I don’t think this language is particularly helpful.
In my mind Debian is an operating system for experts (perhaps
aspiring). Treating users like they are going to hurt themselves if we listen to them is not acceptable conduct in this community in my opinion.
Debian is an operating system for everyone. For experts. For novices. For non-technical users. In any case, even experts often want to have a
break and have things just work without having to write kilobytes of
config.
IMO, the data is already there in all the different (Mini-)DebConf and
email discussion over the past couple of year. If people were just happy >> with /etc/network/interfaces, we wouldn't have this discussion year after >> year after year..
The "data" sources you mention are severely biased in one way or
another. You complain about unusable data above only to suggest even more obviously unusable data here. I don't find this very convincing.
Data point: I’m a previous maintainer of ifupdown. I don’t use it anymore and don’t think it’s a very good default for Debian these days.
I'm afraid all of this will just further delay the decision making for
another year/Debian release.
So what? So far you're the only one complaining about this. What skin do you have in the game if we don't move forward on this other than having an obviously biased interest in having netplan be a standard?
Please, can we have no conflict of interest accusations?
Others might not complain loudly because they don’t have energy to argue (like myself).
Consider that for you time is an ally, being employed to work on this (AFAICT?). For the rest of us not so much. Debian is a primarily a volunteer project. Please stop pushing for doing things faster.
I don’t think Lukas is rushing things too much. We should have had this conversation ages ago. Perhaps I should have started it instead of
resigning as the maintainer back in the day.
On 2 Sep 2024, at 22:56, Daniel Gröber <dxld@darkboxed.org> wrote:
Hi Andrej,
On Mon, Sep 02, 2024 at 09:02:43PM +0200, Andrej Shadura wrote:
On Mon, 2 Sep 2024, at 19:41, Daniel Gröber wrote:
You're continuing to confirm my pre-existing view that netplan infantilizes >>> it's users as you're applying the same thinking to the entire Debian
community here.
I don’t think this language is particularly helpful.
I'm sorry you think so. I'm trying my best to represent my current view as accurately as possible so as to give Lukas a tangible way to try and change it.
In my mind Debian is an operating system for experts (perhapsDebian is an operating system for everyone. For experts. For novices. For
aspiring). Treating users like they are going to hurt themselves if we
listen to them is not acceptable conduct in this community in my opinion. >>
non-technical users. In any case, even experts often want to have a
break and have things just work without having to write kilobytes of
config.
See that's my own biases shining through :)
Ofc. Debian is for everyone. I should have been more clear. When I say this
I think mainly of the base system, servers, routers, embedded stuff and the like. Desktops and other environments already made different decisions and
I respect that.
On a mildly personal note I've just come back from bringing up and running
a large event network as part of the NOC team at Hack ma's castle (an Austrian hacker community event). Since someone on the team decieded to use sd-networkd on the gateway (unsuccessfully) my experience in fixing the network gave me a much better idea of where my tangible problems with it's design lie.
In short: Networking is complicated. I don't think abstraction
helps. Simpler is better. IMO this applies to both sd-networkd and netplan.
Don't get me wrong I'm sure both have valid use-cases, unique features or better ergonomics for some users but those aren't arguments for a change in default.
This also made me wonder: have any of us here actually been in the trenches of networking like I just experienced? If not I return to the idea of the "ivory tower".
IMO, the data is already there in all the different (Mini-)DebConf and >>>> email discussion over the past couple of year. If people were just happy >>>> with /etc/network/interfaces, we wouldn't have this discussion year after >>>> year after year..
The "data" sources you mention are severely biased in one way or
another. You complain about unusable data above only to suggest even more >>> obviously unusable data here. I don't find this very convincing.
Data point: I’m a previous maintainer of ifupdown. I don’t use it anymore
and don’t think it’s a very good default for Debian these days.
I'd love to hear about your perspective and why/where/how ifupdown failed you. I have my own list of gripes with it but I'm still enthusiastic about
my prospects of being able to fix them.
I'm afraid all of this will just further delay the decision making for >>>> another year/Debian release.
So what? So far you're the only one complaining about this. What skin do >>> you have in the game if we don't move forward on this other than having an >>> obviously biased interest in having netplan be a standard?
Please, can we have no conflict of interest accusations?
It's not an accusation, just an observation. I don't resent Lukas doing
this. I don't think it's wrong. If netplan was my project you better
believe I'd be here doing the same thing.
Others might not complain loudly because they don’t have energy to argue >> (like myself).
I try not to weight complaints by loudness TBH. A short statement would do just as well.
Consider that for you time is an ally, being employed to work on this
(AFAICT?). For the rest of us not so much. Debian is a primarily a
volunteer project. Please stop pushing for doing things faster.
I don’t think Lukas is rushing things too much. We should have had this
conversation ages ago. Perhaps I should have started it instead of
resigning as the maintainer back in the day.
How late the conversation is doesn't change how long it takes to have it properly. I can tell you for sure that a year or so ago I wouldn't have
been involved so things would have been much less complicated ;P
--Daniel
Hi, I second Hakan's thoughts and reasons for using NetworkManager
going forward, as opposed to netplan. I work in a company which ships
boat loads of network devices (think industrial routers, GSM gear,
factory equipment) running a wide variety of Linux from Ubuntu, RHEL,
Debian, etc. The way NetworkManager (including nmcli commands)
interoperate seamlessly between RHEL land, SUSE, Arch, Gentoo and Ubuntu(maybe Debian) helps a lot with maintaining complex network
appliances which run on everything with minimal effort. Think multiple
VLANs on GSM connections, testbeds with hundreds of network namespaces (managed with NetworkManager), docker fleets with predictable network topology, etc.
All of this is very much possible and reasonably well documented with NetworkManager+systemd-networkd.
I also think using a system which most of Linux land already uses can potentially drive talent to maybe help with NetworkManager integration
here. There's waay more knowledgeable people in NM land than in netplan
in my opinion. On a more personal note, I enjoy using NetworkManager
more than netplan as well, I find the syntax and nmcli way easier to
use and harder to result in a borked network config. I also think my
personal preference is of little importance, compared to my
professional experience with both networking systems.
I’m a system administrator, and with my colleagues, we manage
approximately 1200 servers from physical installation to managing
users’ applications and everything in between. This includes network
design, wiring and implementation.
To be honest, not of our fleet is completely Debian, but many are,
and I personally prefer to work with NetworkManager rather than
Netplan. The reasons are numerous.
My position is that I am happy for Debian to have the option of netplan
but I do not think that it should be installed by default, because it is
an abstraction which adds complexity and that nobody asked for other
than its developers.
And this is an orthogonal issue with deciding if ifupdown is appropriate
for a modern system (I have been using it for close to 30 years and at
this point I think that it has served its purpose and there are better defaults...).
The nice thing about Netplan is that it [...] functions as a
layer on top.
On 9/3/24 18:24, Lukas Märdian wrote:
The nice thing about Netplan is that it [...] functions as a
layer on top.
I don't understand what actual problem netplan is trying to solve.
* Marco d'Itri <md@Linux.IT> [240903 14:04]:
My position is that I am happy for Debian to have the option of netplan
but I do not think that it should be installed by default, because it is
an abstraction which adds complexity and that nobody asked for other
than its developers.
And this is an orthogonal issue with deciding if ifupdown is appropriate
for a modern system (I have been using it for close to 30 years and at
this point I think that it has served its purpose and there are better
defaults...).
I want to echo all of this. All my customers sites are currently
migrating away from ifupdown to networkd, and they don't need or
want an intermediate layer.
For the desktop(-like) systems, NetworkManager works nicely, again
without a need for an intermediate layer.
Again, having the option is nice. But I don't see netplan as a
useful default.
On Wed, 4 Sep 2024 11:27:45 +0200, Chris Hofstaedtler
<zeha@debian.org> wrote:
* Marco d'Itri <md@Linux.IT> [240903 14:04]:
My position is that I am happy for Debian to have the option of netplan
but I do not think that it should be installed by default, because it is >>> an abstraction which adds complexity and that nobody asked for other
than its developers.
And this is an orthogonal issue with deciding if ifupdown is appropriate >>> for a modern system (I have been using it for close to 30 years and at
this point I think that it has served its purpose and there are better
defaults...).
I want to echo all of this. All my customers sites are currently
migrating away from ifupdown to networkd, and they don't need or
want an intermediate layer.
For the desktop(-like) systems, NetworkManager works nicely, again
without a need for an intermediate layer.
This, and this.
Again, having the option is nice. But I don't see netplan as a
useful default.
And, choosing Netplan as a default doesn't solve the issue, since we'd
still have to decide what we'd use below it by default, leaving us
with the same hard decision: NetworkManager which bears its mock name NetworkDamager for a reason, systemd-networkd which is kind of
unsuitable for desktop(-like) systems, comes from the much-hated
systemd world (thus igniting a systemd debate everywhere it is
mentioned) and contains way to much not-invented-here code regarding
IPv6, or ifupdown, which is outdated if I'm being friendly, and a
Debianism.
On Wed, 4 Sep 2024 13:28:30 +0200, Daniel Baumann <daniel@debian.org>
wrote:
On 9/3/24 18:24, Lukas Märdian wrote:
The nice thing about Netplan is that it [...] functions as a
layer on top.
I don't understand what actual problem netplan is trying to solve.
I am also missing that piece of information. At the moment, I see
netplan as an implementation of RFC 1925 Clause 6a, with a very
friendly and motivated upstream. When I feel evil, I'd say it's just
another Ubuntuism.
That's not enough for me to consider Netplan. So I'm going to stay
with network manager on my mobile boxes that need Wi-Fi, and
systemd-networkd on everything else.
On 9/3/24 18:24, Lukas Märdian wrote:
The nice thing about Netplan is that it [...] functions as a
layer on top.
I don't understand what actual problem netplan is trying to solve.
On servers I want systemd-networkd directly anyway (for lacp, vlan and bridges), and on end-user desktops I'm not modifying anything other than selecting the WLAN.
Is netplan then only ment for "power-users" who don't want
systemd-networkd or need a everything-in-one-file oversimplification of systemd-networkd?
With Netplan we could provide coherent network configuration across all variants of Debian (server, cloud, laptop, ...), while choosing the best underlying stack for the usecase (i.e. systemd-networkd on server/cloudOf course we could. But who would actually care?
and NetworkManager on desktop/laptop).
Yes, it's an additional abstraction layer, but it brings the big benefitXKCD 927
of coherence across Debian. Not confusing our users by having 4 different ways to do network configuration.
In our documentation we could reference a single Netplan configuration,Do we even have general documentation about configuring networking?
that would get applied to both of the underlying stacks. As stated previously, advanced users can easily configure the underlying stack
natively and Netplan will get out of their way.
With Netplan we could provide coherent network configuration across allOf course we could. But who would actually care?
variants of Debian (server, cloud, laptop, ...), while choosing the best
underlying stack for the usecase (i.e. systemd-networkd on server/cloud
and NetworkManager on desktop/laptop).
Yes, it's an additional abstraction layer, but it brings the big benefitXKCD 927
of coherence across Debian. Not confusing our users by having 4 different
ways to do network configuration.
In our documentation we could reference a single Netplan configuration,Do we even have general documentation about configuring networking?
that would get applied to both of the underlying stacks. As stated
previously, advanced users can easily configure the underlying stack
natively and Netplan will get out of their way.
But in the end we don't want to bloat our base-installation with NetworkManager and systemd-networkd is not fit to cover the desktop/laptop usecase. So why not put some glue around it, to make it all feel coherent, without limiting anybody in their decision to choose whatever stack they like?
Netplan is for the average user who googles about "how to configure network on debian" and ends up with the "4 ways to configure the network"
[4ways] or
even more options in the Debian Reference [debref]:
Now, what configuration does the average user chose, without necessarily knowing the underlying stack?
With Netplan we could slowly converge to a
set of instructions that work everywhere. While at the same time we could still
support/provide two modern upstream stacks (NetworkManager & systemd-networkd) for everybody's liking.
But we ought to look at the bigger picture!No distribution other than ubuntu is using it.
From that point of view, it doesn't make sense to even consider netplan.
Of course we could. But who would actually care?
That's exactly the problem!
But we ought to look at the bigger picture! People looking from the outside in will get very confused by the scattered Debian networking landscape.
But in the end we don't want to bloat our base-installation with NetworkManager and systemd-networkd is not fit to cover the desktop/laptop usecase.
Which one to choose? Well it all depends on the underlying stack, which
the average user might not necessarily know. So it's very confusing.
"wild idea": how about just removing ifupdown/ifupdown2/ifupdown-ng and >decluttering/improving documentation instead then?
I don't see a problem with keeping ifupdown{2,-ng,} if none of those
packages is part of the default install and we remove it from the
beginner- and intermediate-level docs.
On 9/5/24 10:43, Marc Haber wrote:
I don't see a problem with keeping ifupdown{2,-ng,} if none of those
packages is part of the default install and we remove it from the
beginner- and intermediate-level docs.
right, me neither; but Lukas' argument was that introducing netplan is "unifying documentation" which there are better ways to get to that (one
of which you just suggested too, thanks).
sorry, one more..
On 9/4/24 18:00, Lukas Märdian wrote:
But we ought to look at the bigger picture!
From that point of view, it doesn't make sense to even consider netplan.No distribution other than ubuntu is using it.
If Debian uses network-manager and systemd-networkd, there's hardly any difference in the configuration wrt/ to the other major distributions,
so, *that* has the potential to unify documentation.
or in other words: If you would truly care for that then let's use the
chance to *remove* some Debian-isms (ifupdown and friends) from the "big picture", rather than further *adding* more divergence by fostering netplan.
But for the
release where we switch our network stack, we should definitely keep it >around, to give sysadmins some time to adopt to the new recommended tooling.
On 5 Sep 2024, at 16:07, Lukas Märdian <slyon@debian.org> wrote:
On 04.09.24 21:41, Daniel Baumann wrote:
sorry, one more..
On 9/4/24 18:00, Lukas Märdian wrote:
But we ought to look at the bigger picture!No distribution other than ubuntu is using it.
From that point of view, it doesn't make sense to even consider netplan.
If Debian uses network-manager and systemd-networkd, there's hardly any
difference in the configuration wrt/ to the other major distributions,
so, *that* has the potential to unify documentation.
Except that others recommend only ONE tool and stick to it, while Debian would recommend two at the same time. (Three actually, as Netplan is used
in our cloud-images.)
That's exactly what leads to confusion.
* Fedora/RHEL recommends NetworkManager
* Ubuntu recommends Netplan
* For others like Arch Linux or Gentoo, people choose their stack explicitly,
so it doesn't really matter.
Debian would recommend NetworkManager for desktop/laptop, systemd-networkd for server, Netplan for cloud. And people would need to do their research
to understand what stack they are on, to then better understand how to control it.
or in other words: If you would truly care for that then let's use the
chance to *remove* some Debian-isms (ifupdown and friends) from the "big
picture", rather than further *adding* more divergence by fostering netplan.
I'm all for removing Debian-isms, but I guess that's a discussion for another year...
Agreeing on Netplan would provide us with the hybrid stack that you described above, but without the confusion. Furthermore, it's been proven in Ubuntu for 7+ years, so lots of edge-cases have already been hit and handled.
Cheers,
Lukas
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.
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.
On 04.09.24 17:26, Marco d'Itri wrote:
Do we even have general documentation about configuring networking?
Yes, there is a "NetworkConfiguration" page on the wiki and the Debian ref:
* https://wiki.debian.org/NetworkConfiguration
* https://www.debian.org/doc/manuals/debian-reference/ch05.en.html
Together, they show something like 5+ ways of how to do things:
* /etc/network/interfaces
* iproute2
* Netplan
* NetworkManager
* systemd-networkd
Which one to choose? Well it all depends on the underlying stack, which
the average user might not necessarily know. So it's very confusing.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 02:42:05 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,584 |