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