Re: r228700 can't dhclient em0

On Wed, Dec 21, 2011 at 04:55:40PM +0400, Gleb Smirnoff wrote:
>   Brooks,
> 
> On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote:
> B> While this is the documented path, it's not actually been required
> B> except in edge cases for ages (the last I can remember is a.out->elf).
> B> It's been long enough that I don't think we can really make people do
> B> it except for a short period of time in HEAD.  I believe it's
> B> unacceptable for a release to release upgrade.
> 
> I have provided API compatibility in r228768. I have tested it with an
> ifconfig binary taken from 9.0 installation. I hope, this change
> would satisfy you, and you won't say that "We almost certainly need to
> back r228571 out".

Thank you!  I spoke too strongly there.  I was worried that we would 
end up in an untenable situation, but you appear to have resolved it.

> The in_control() and in6_control() are getting more and more hairy :(
> I'd eager to remove the shim in the 11.x timeline.



> Since subject mentions "dhclient", I must notice that the dhclient-script
> always relied on a bug in in_control(). The bug was fixed here:
> 
> http://svnweb.freebsd.org/base?view=revision&revision=228313
> 
> Later the dhclient-script was fixed:
> 
> http://svnweb.freebsd.org/base?view=revision&revision=228463
> 
> So, if we are claiming for an undocumented but important feature
> that new kernel being capable to configure network with world from
> a previous major release, then I should merge r228463 right now
> to stable/9, and not merge r228313.
> 
> If I don't merge r228463 before 9.0-RELEASE is out, then in
> 2 years, 10.x-RELEASE kernel won't bring network up via DHCP with
> world from 9.0-RELEASE. Thus, should I now either bribe re_at_ to push
> r228463 prior to release, either back out the bugfix: r228463.

You and bz have convinced me that for the configuration tools tools this
change breaks, that it should be OK to have only supported 9.x releases
(or possibly even only the last 9.x release) be able to upgrade without
extra effort.  I took too strong a position to start out.

> Also, backing out r228463 would require backing out a larger
> work: r228455.
> 
> Hey, this policy greatly discourages hacking on bugs and new
> features... :(

I hope we're approaching a more acceptable position...  I don't want to
discourage fixing bugs or adding features and more than having to deal
with users inevitably does.

-- Brooks