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