The getopt long thing breaks the tree.

[Rob Landley]

On Friday 02 June 2006 3:14 pm, Bernhard Fischer wrote:
> >This trend is normal.  When the mainline gets bloated enough, a
> > slimmed-down fork emerges.  Dropbear vs openssh.  Galeon vs Mozilla (and
> > Firefox vs Galeon, and it's still kinda bloated.)  xfce fs kde/gnome. 
> > uClibc vs glibc, and BusyBox vs most of the GNU tools.
>
> Yes. So how is providong means to ignore non-standard extensions which
> make busybox (as a binary) bigger a bad thing? That's really all what
> the getopt_long thing did. Nothing fancy, nothing intrusive.

Something that can make busybox smaller on all platforms needs no further 
justification. :)

> >"The nice thing about standards is that there are so many to choose from."
> > - Andrew S. Tanenbaum, many years ago...
> >
> >My lack of caring is deep and profound.  I'm not a fan of the LSB.  There
> > are multiple conflicting standards.  Wheee.  The application section of
> > SUSv3 is incomplete, but vaguely sane.  (Only vaguely: We're not
> > implementing sccs.) And thus is the frame of reference from which we can
> > document how we diverge when we get around to auditing things.
>
> I was under the impression that SUSv3 also implied that we should try to
> provide a working, minimal set that only uses SUSv3. More fancy features
> building ontop of eventual extensions should be optional --
> configurable.
>
> Apparently this is not the case, do i understand you correctly?

I'm not against having both projects, but they're separate things.

Providing an susv3 conforming environment is something I know how to test, by 
creating a test suite from reading susv3.  Running in a purely susv3 
environment isn't something I don't know how to test, because no non-toy 
environment is purely susv3 (it wouldn't even be able to boot without 
including stuff that's not in the spec).  And if we work in some theoretical 
pure susv3 environment but find out that approach sucks on Linux or MacOS X, 
that's still no good.

For the first thing, us providing extensions beyond susv3 is not a problem.  
For the second thing, us using extensions beyond susv3 _is_ a problem.  But 
some of those extensions do indeed make us smaller, so there's an inherent 
conflict here, and to resolve it we'd either have to accept sub-optimal 
solutions on a regular basis or else implement stuff twice, which fights 
against the goal of simplicity of implementation.

It's not necessarily an unresolvable problem, but the two issues are _not_ the 
same thing.

> >> > Working around specific deficiencies in the Linux emulation of other
> >> > platforms are just that: workarounds.
> >>
> >> Other platforms have no reason to emulate "Linux" (GNU/Linux). Doing
> >> so will make them necessarily bloated and bogged down by legacy crap.
> >
> >I have no reason to care about those other platforms that are neither
> > Linux nor remotely compatible with it.
>
> Well, in case of getopt, one platform adhered to SUSv3, so according to
> the probably wrong assumption that we aimed for SUSv3 as the (minimum)
> base,

That we provide, not that we run on...

> i thought that it would be good to be able to *run* busybox on 
> platforms that adhere to SUSv3. That may not have been a valid
> assumption, though..

In the specific case of getopt() that permutes our arguments, you're right it 
sucks and it's possible that doing away with it would help everybody, Linux 
included.  Parsing command line arguments to a set of flags and option 
strings shouldn't be brain surgery, and if we're gluing enough crap onto the 
front of the library function already, it's possible that by not using the 
library function at all we'll wind up smaller.  Even the function's 
implementation doesn't shrink, if the lack of permutation means that more 
apps can use it, and we avoid bugs like the "tar xvjfc" thing, the better 
behavior might be worth a sufficiently small size penalty.  It's very much 
worth a look.  For 1.3.0.

It's possible to arrive at the same goal through different means, and the same 
implementation for different reasons.  When I say "that's not a compelling 
reason for me" that's not the end of the argument, but it does mean that 
hammering on that reason over and over, ignoring what I said, is likely to 
annoy me. :)

Rob
-- 
Never bet against the cheap plastic solution.