Inetd.c sigpause() --> __xpg_sigpause() not in uClibc

[Rob Landley]

On Thursday 10 November 2005 02:30, Vladimir N. Oleynik wrote:
> >>Now it's quite possible that, in this case, resynching with the BSD
> >> version was the right thing to do.  But I never saw vodz make that case.
>
> Unless it is discussion? It is market bedlam.

When I rewrote sed, sort, bunzip, and mount, I let the list know what I was 
doing.  I posted them all to the list before throwing out the old version, 
tried to explain at least some of the advantages of the new version, and made 
sure everybody knew it was coming and had plenty of time to object.  The new 
test suite is going in beside the old test suite.

> Instead of offering correction on one line,

Your change-everything patch wasn't one line, and this isn't the first bugfix 
your "resync" has required.  I'm asking why we're synced with an external 
source that isn't size-optimized in the first place.  What is the advantage?

Yes, a patch for this specific bug fix is easy.  I'm woried about strategy and 
direction here.  I just built two versions of busybox (1.01 and -current) 
that had nothing but inetd in them (1.01 had all options enabled, 1.1 had 
just the options that 1.01 offered enabled).  The result is that -current is 
500 bytes larger than the 1.01 version.

Why is this an improvement?  What is the reason for the change, and why can't 
we configure  whatever it is out to get the smaller one back?  (Is the answer 
"oh, it's only 500 bytes, don't worry about it?")

> and the most important - to transfer the initial mainstream author,

I don't care what the "mainstream" author did.  It has never been a 
requirement of busybox that we have the same implementation as external 
programs.  In fact, when we _do_ track external programs too closely it's 
generally an indiciation that we're missing optimization opportunities (if 
nothing else, making use of libbb).

I'm all for looking at the changes the mainstream author made and seeing if 
they may apply to the busybox.  And there are instances where an external 
version is good, clean, tight, readable code that doesn't do anything we 
don't need it to, so there's nothing to trim out.  Are you saying this is the 
case?

> have made a lot zilion kilobyte of bla-bla, frequently offensive.

In this particular thread, I keep asking questions you never answer.  (The 
alternative is reverting the change, which would be rude and which I'm trying 
_not_ to do.)  If you have a personal problem with me that interferes with 
your ability to answer technical questions, let me know.  (I'd email you off 
the list, but you've been spam-blocking my email for over a year, and don't 
seem to care.)

You seem to be saying I've insulted you with empty talk by asking you 
to explain why you replaced the version of inetd we had with a wildly 
different version, masquerading as a bug fix for something that it _seems_ a 
2-line patch existed for?

> On this empty chatter at you time is...

The "empty chatter" is the alternative to reverting the patch.  Would you 
rather I check in what _I_ think the fix is?

I've held off touching the code because what _I_ would do is revert the change 
that bloated it by 500 bytes, added a lot of ugliness (including a minor 
license conflict), and had no explanation given for why such a huge change 
was put in in the first place.

But I'm not the maintainer of inetd, and I don't want to _become_ the 
maintainer of inetd, because I don't use inetd.  Therefore, I ask my question 
again.  What was the advantage of resyncing with the external version of 
inetd, which was worth 500 bytes and the need for multiple bugfixes?  Is it 
just resyncing in the name of resyncing, or is there more?

Rob

P.S. Your entry in AUTHORS says "irreconcilable critic of everything not 
perfect".  So why aren't _you_ the one bringing up the fact that the patch is 
500 bytes bigger for the same set of options and introduces ugly idioms like 
defining a macro, using it on the next line, and undefining it on the one 
after that?