[systemd-devel] [PATCH 17/17] networkd: add dhcp server support

Tom Gundersen teg at jklm.no
Tue May 27 08:32:00 PDT 2014


On Tue, May 27, 2014 at 4:04 PM, Eelco Dolstra
<eelco.dolstra at logicblox.com> wrote:
> However, to be honest, I've never really understood why
> networkd needs to be part of systemd in the first place. It seems to me that it
> would work just as well as a separate package with its own releases. To me as a
> downstream that would be preferable, since such a package can be upgraded
> (mostly) independently from systemd. For instance, in NixOS we can upgrade
> dhcpcd or wpa_supplicant pretty much in isolation from the rest of the system;
> but getting the latest networkd would require getting the latest systemd, which
> is typically a much bigger step since it potentially impacts much more of the
> system.
>
> You often point out (correctly) that systemd is not monolithic as it consists of
> dozens of separate programs. But it *is* a monolithic package: those dozens of
> programs can only be upgraded as a set.

networkd is no different from any of the other systemd daemons in this
regard. It could be shipped and upgraded separately from systemd (if
you make sure you know what you are doing, this is not something we
suggest nor test for), and it could even be hosted in its own code
repository. However, that would duplicate a lot of code, and create a
lot more work for everyone involved. So we are not doing that.

> A package becomes a monstrosity one "small" feature at a time. (And one person's
> bloat is another person's essential feature.) For instance, networkd currently
> lacks a WPA supplicant, which you surely need in a modern system. So should
> systemd accrete a WPA supplicant? How about Bluetooth support?

I would argue that support for Bluetooth and/or WPA should be separate
from networkd itself. I'm currently using networkd on top of
wpa_supplicant on my laptop and it works just fine (I mean, it is
still wpa_supplicant, so my definition of "fine" is a bit flexible,
but at least in theory setup seems to be the right one).

> Etc. etc. I mean,
> is there any concrete criterion about what should or shouldn't go into systemd?

We want to include precisely those things that make sense :P

Cheers,

Tom


More information about the systemd-devel mailing list