Date: Sun, 15 Dec 2002 12:26:32 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Nate Lawson <nate@root.org> Cc: current@FreeBSD.ORG Subject: Re: ipfw userland breaks again. Message-ID: <200212152026.gBFKQWIa093377@apollo.backplane.com> References: <Pine.BSF.4.21.0212151157240.44745-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200212152026.gBFKQWIa093377>