Re: DHCP server in base

2010/9/11 Doug Barton <dougb_at_freebsd.org>:
> On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote:
>>
>> Hi,
>>
>> another argument about hostapd :) if have access point we must have
>> way to assign IP for AP clients.
>
> To start with, your assumption is wrong. DHCPd is not *actually* a
> requirement, although I admit that practically it is.
>
>> Last spring I made firmware based on FreeBSD for router with only 4MB
>> NOR flash (D-Link DIR-320).
>
> In this category (micro-miniaturization) you're already in the "significant
> customization needed" area, which means that general arguments about "the
> base" don't apply.
>
>> Since this device is router I must be
>> able to serve DHCP. And current implementation of dhcpclient, that we
>> have, is same isc-dhcp, and I replace system dhcpclient with ports
>> one+dhcpd but with small patch that put basic dhcp utils onto
>> libdhcp.so.
>
> Your argument is creative and well thought out, but I personally don't find
> it persuasive. Counter arguments that come immediately to mind are:
> 1. The DHCP server is not going to benefit any but a small minority of
> FreeBSD users.
> 2. The software is already available in the ports tree, and adding a
> port/package of it really is not an overwhelming burden.
>
> More generally, the main reason I want to keep more stuff out of the base,
> and remove some of the stuff that's in there now, is that it makes
> maintenance difficult across FreeBSD branches. We have a general policy that
> if we have a major version N of something in a release branch that we don't
> upgrade that major version without a really good reason to avoid POLA
> surprises for our users. Once again using BIND as an example, this has led
> to a really old and past-EOL version of BIND in FreeBSD 6 which I've only
> gotten away with because anyone doing serious DNS work nowadays has to
> upgrade to at least 9.6 anyway. But it's an ugly situation, and I don't want
> to repeat it.
>

I agree but like Aleksandr said, almost 70% of dhcp code is already in
base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea
to keep some parts in the ports tree and move out from the base.

Perl is a great example, I don't really understand why it's in the
base, then the port need to rewrite the links into the base hierarchy
and I think this is bad.

> The problems get worse and/or more complex with the more 3rd party stuff you
> start including in the base. In part because of the product lifecycle issues
> that are similar to BIND's, but also due to the possibility of licensing
> issues (such as with gcc and/or other GPL software) and other more esoteric
> factors.
>
> Even with home-grown stuff like our pkg_* tools we have problems because
> when we want to introduce new features (or deprecate old ones) there is
> currently a _minimum_ 3-year cycle we have to follow in order to make sure
> that the new feature is/is not available on all supported versions of
> FreeBSD. That's the main motivation behind my continuing to repeat the
> suggestion to move those tools specifically into the ports tree so that we
> can better support innovation in our ports/packages system.
>
> In my view what we've needed to do for a long time now is to seriously strip
> down the notion of what "the base" should be to those items that are needed
> to work together for a specific API/ABI/AKI release, and move everything
> else into the ports tree. (Obviously there would be some exemptions made for
> really basic/vital stuff like ls, etc.) We can do this in a way that finds a
> middle ground between the linux model where literally everything is a
> package and the traditional BSD model of providing a "complete system,"
> which is hardly ever true since I've never been involved with any FreeBSD
> system administration where there were absolutely no ports/packages
> installed at all.
>
> Such a system could also be streamlined by creating a ports virtual category
> (something like "system") the packages for which could be included in the
> install media as long as we are judicious about what goes in there. Things
> like wpa_supplicant, dhclient, DNS tools, etc. could all be in that
> category, and all we'd have to do to make that work is to very slightly
> expand the list of questions that sysinstall already asks.
>
> So this is a much longer version of my previous response which hopefully
> gives you more background about why it's a bad idea to add *any* more 3rd
> party stuff to the base.
>
>
> Doug
>
> --
>
>        ... and that's just a little bit of history repeating.
>                        -- Propellerheads
>
>        Improve the effectiveness of your Internet presence with
>        a domain name makeover!    http://SupersetSolutions.com/
>
>



-- 
Demelier David