What it comes down to is what developers are willing to do. My
contribution is 'ipfw unbreak'. If someone else has a solution that
they are willing to work on and commit in the next four weeks, then
fine. But if nobody is willing to work on and commit another solution
in the next four weeks then I should be able to commit my solution now,
which really isn't all that bad hack or not.
Any build-related solution would have to be handled by both installworld
and installkernel. Consider the fact that most developers, when working
on -current, install the kernel far more often then they install the world.
An API check during the installkernel would work almost as well for my
own purposes as 'ipfw unbreak'. It doesn't provide a failsafe but it
does handle the most common installation case.
Note that this solution may not be quite as simple as it appears, since
-current may be built on a -stable box so compiling up an out-of-date
ipfw is not entirely trivial.
My current solution is on the table. I see no others on the table at
the moment.
-Matt
:One other avenue would be to stick a temporary check for ABI compat in
:installworld before overwriting ipfw. Or for the next few releases, build
:both ipfw1 and ipfw2 and install both (say, symlinking ipfw -> ipfw2 by
:default). You could fall back to ipfw1 if ipfw2 returns an error code in
:rc scripts. I'd prefer this kind of hack in the install/rc process, not
:in a new API.
:
:Regarding civility to developers, there are a ton of frustrating things in
:any project. I think civility should be the response given to both
:reasonable and unreasonable people. If they are unreasonable, giving a
:reasonable response just makes them look bad.
:
:-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
