Re: isc-dhcpd vs udhcpd
Just to rephrase my original request then...
Personally, I don't really care about the DHCP client used in d-i, but I
do care about complexity in the bind9 packaging.
The --without-openssl support will go away (probably in BIND 9.13) and I
would rather unify the two sets of libraries into one. If that means
shuffling symbols around, so we don't end up with libxml2, libjson and
libgeoip in d-i, then I will rather make it happen in upstream
So the main difference between export and non-export libraries are:
Are these a problem?
* krb5 / gssapi # guess this is a problem, as krb5 has not udebs
* libcap2 # guess not, there's a udeb
These have to definitely go:
* libgeoip1 (I have no idea why it's linked to libisc)
* libxml2 (I have no idea why it's linked to libisc)
Cheers,
Ondrej
--
Ondřej Surý <ondrej@sury.org>
On Mon, Oct 23, 2017, at 13:21, Philipp Kern wrote:
> On 23.10.2017 09:36, Ondřej Surý wrote:
> > while revising bind9 udebs, KiBi suggested that non-Linux architectures
> > might be using isc-dhcpd instead of udhcpd due some problems and it
> > might be a good idea to revise the decision now that we have a busybox
> > maintainer?
>
> Ubuntu has used dhclient for a long time now in d-i. I think there are
> at least two parts to it: a) consistency across architectures - it is
> weird to support two completely different implementations and b)
> actually use the same implementation than the installed system would
> rather than something embedded that has less features.
>
> I recall times at work where we had severe issues with dhclient not
> staying around in the background refreshing the lease. I have no idea if
> this is still the case, I just recall that -1 behavior was kind of a
> mess. Back then we bumped the lease duration. If picking udhcpc means
> that we can address such issues more easily, that's better.
>
> At the same time people know how to configure dhclient and can use a
> similar config as in the installed system. My understanding is that
> udhcpc has essentially no options at all (like sending additional DHCP
> options).
>
> netcfg also did not receive that much love in recent times and I wonder
> if something more integrated wouldn't be better than the hacks layered
> on top of each other to make it work we have today. But at the same time
> I know that something modern like systemd-networkd won't work for d-i
> either because of architecture consistency. :/
>
> Kind regards
> Philipp Kern
Reply to: