udhcp missing prototypes
Rob Landley
rob at landley.net
Wed Apr 19 21:11:15 UTC 2006
On Wednesday 19 April 2006 1:50 pm, Mike Frysinger wrote:
> On Monday 17 April 2006 23:18, Rob Landley wrote:
> > I'm removing that entire subdirectory.
>
> here's a better idea, leave it alone
I was doing so, until another project got nailed to the side of busybox.
> we get it, you dont like udhcp
I think udhcp is fine as a separate project. But either it's a separate
project, or it's a part of busybox. There is no middle ground.
> let other people field the questions then, all you're doing is adding noise
> at this point
I am not cutting a release that has an external project glued to the busybox
svn repository. Period. Ever. There will not _be_ another -devel release
before I remove that, and if absolutely necessary I will manually rm -rf that
directory from the copy I tar up.
I objected when the symlink was put in, apparently not strongly enough. If
I'd had a little more warning, I would have cleaned up the udhcp code use
getopt_ulflags() and all the other libbb stuff, but right now I can't do so.
Not because it would break building it outside of the tree (which isn't my
problem), but because I'd have to rm -rf my svn repository and re-check it
out in order to have access to that directory at all again.
This has not been a high priority for me since the next release isn't slated
until June, and if necessary I can just delete the sucker. (I'd rather not
do that though, since that would be a functional regression.)
But the current udhcp code was doomed from the moment you deleted busybox's
copy of it. When you deleted busybox's copy, it ceased to be part of
busybox. Splicing in an external tree is irrelevant: that doesn't ship.
> -mike
Rob
--
Never bet against the cheap plastic solution.
More information about the busybox
mailing list