svn commit: trunk/busybox: coreutils include

Rob Landley rob at landley.net
Mon May 8 01:50:32 UTC 2006


On Sunday 07 May 2006 8:21 pm, Mike Frysinger wrote:
> > You deleted busybox's udhcp directory.
>
> thank you for pointing out the obvious, we've been over this already

And yet it wasn't resolved.  Now it is.

> > There isn't one in busybox anymore.
>
> because there were no differences

Because people who weren't me were continually resyncing them, which was fine 
as long as somebody else had to worry about resolving conflicts.  I checked 
in submitted patches that were good for busybox (and didn't care what they 
did to an external tree they weren't applied to), and I avoided some obvious 
cleanups in that directory because I didn't want to bring the situation to a 
head, but once it was _brought_ to a head I could no longer ignore it.

> as i said before, if you want to fork it, then do so, otherwise leave it
> alone

I was happy to leave it alone, before it got deleted.  The symlinked directory 
is not something I will ever ship.  Perhaps I had not made that sufficiently 
clear: If I have to add an rm -rf step to my packaging script, I will.

It was a mistake on my part not to immediately check in the changes to 
applets.h and such that I had to make to get the project to build again for 
me after you deleted udhcp.  That meant that the svn server was out of sync 
with what I was actually going to ship, which is not a good thing and may 
have given you a false impression.  When those bits did leak into the tree, 
you reverted them several times as if it somehow made a difference.  It did 
not.

> > Were you not listening when I said I wasn't going to ship things bolted
> > onto the tree with "busybox" painted on the side, or did you think I
> > didn't mean it?
>
> and you didnt follow up to the e-mail where i said to either busyboxify it
> or leave it the hell alone

I ignored your ultimatum, you mean?  I thank you for the offer that I spend my 
time to clean up the mess you made, but I respectfully decline.  I'm not the 
one who broke it, and telling me to fix what you broke when you'd only revert 
it again if I did the obvious fix (I.E. revert it back to the separate 
directory you deleted, and worry about cleaning it up when I get around to 
it) is silly.

I refuse to lose the _option_ to clean it up, even though I have many other 
things to do at the moment.  Your insistence that I either drop what I'm 
doing and work on this right now or accept bolting an external project onto 
the tree as a valid thing to do is something I ignored, yes.

Also, my svn was broken by your change, and until just recently I hadn't sat 
down with the redbook to learn how to fix it.  It wasn't a priority since I 
have no interest in making an external symlink work properly.

If someone would like to add dhcp support to busybox, I'm all for it, but ever 
since you deleted it, it hasn't got any.  I'm just making svn match what will 
ship.

And yes, I've poked at writing a replacement dhcp client and server over the 
past month, and made decent progress (it's not brain surgery), and at this 
point that's closer to being done than working from the other end by cleaning 
up a udhcp fork to be a proper busybox applet.  But the new dhcp client and 
server are just two of the many unfinished projects in my tree vying for my 
programming time.  They weren't even on my radar at the time of the 1.1.1 
release.

On a side note, I would consider it extremely rude to check something into the 
udhcp maintainer's tree without asking.  I've never even asked him for 
permission to do so.  I test the changes that go into the busybox tree, and 
if something turns out to be broken I can generally fix it up.  I can't do 
that for an external udhcp package I don't even use, and I will not be held 
responsible for it.

Obviously you don't understand why I object.  I've tried to explain myself, 
but the fundamental issue is I won't ship an external project that I can't 
make busybox-specific changes to without having to worry about an angry email 
from some other project's maintainer because I broke his stuff in a way that 
I don't build and test.  The fundamental issue is I will not ship that.  I 
can keep repeating that until you either understand it or accept the reality 
of it without understanding why.  I will not ship it.

> -mike

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list