The getopt long thing breaks the tree.

[Rob Landley]

On Wednesday 31 May 2006 9:40 pm, Rich Felker wrote:
> On Wed, May 31, 2006 at 05:27:58PM -0400, Rob Landley wrote:
> > > What i, personally, care about is standard compliance; There simply is
> > > no such thing like getopt_long nor "struct option".  See
> > > http://www.opengroup.org/onlinepubs/009695399/functions/getopt.html
> >
> > There's no such thing as mount in the darn standard either.  You should
> > stop using it immediately.
>
> The standard omits mount for a very good reason: not that it should
> not exist, but that specifying such low-level, administrator-specific
> things is not the job of the standard but of the particular
> implementation.

It is not a complete spec, and it doesn't say we can't rely on things that 
aren't in the spec.

There's a difference between the environment we _provide_ and the environments 
in which we _build_ and _run_.  Pointing to the spec for the environment we 
provide, I'll look at.  Pointing to the spec about the environment in which 
we build and run is something about which I _DO_NOT_CARE_.  The environment 
in which we build and run is Linux.  There are specs out there that say what 
a Linux environment should look like.  The Linux Standard Base is one of 
them.  86open was another (which was pretty big in its day, see 
http://www.educ.umu.se/~bjorn/mhonarc-files/debian-announce/msg00064.html ), 
which decided "a common binary standard for x86 Unixes is pointless, just run 
Linux binaries".  Yes, literally: see http://www.telly.org/86open

Working around specific deficiencies in the Linux emulation of other platforms 
are just that: workarounds.  You're bitching about an upstream spec that 
doesn't specify _init_, so by itself it won't even _boot_.

> On the other hand, it's reasonable to assume that apps 
> which have nothing to do with low-level, implementation-specific
> issues like mounting filesystems and configuring the network should be
> able to get by with only the standard interfaces, and work
> out-of-the-box on any (mostly-) posix compliant system.

If you talk about "this test case breaks on MacOS X", that's real.  If you say 
"this does not conform to the spec" I'll show you a spec it conforms to, even 
if it's the gcc man page or Johnathan Corbet's Linux device drivers book.

> I apologize that you feel like these issues are wasting your time.

No, I feel they're introducing new goals to the project.  We try to provide a 
SUSv3 environment, but A) that's just an config option, B) what we provide it 
on is Linux and things that are more or less compatible with Linux.  Changes 
to support non-linux platforms which require such extensive changes to 
BusyBox that they can't be confined to something like platform.h may not be 
worth doing.

> Would it perhaps be better if the people who care about them try not
> to bother you with issues that will make the code "dirty" (like
> ifdefs) and instead try to develop a clean way of handling these sorts
> of issues that will be acceptable to the way you want the project
> maintained?

How much OSX support did Erik do?  How much did Bruce Perens do?

Saying "MacOS X doesn't have a getopt implementation that does this" is one 
thing, and the obvious thing to do is implement the missing piece to overcome 
the deficiency in MacOS's Linux compatability.  Saying "getopt is linux 
specific and therefore broken, so we shouldn't use it" is BY DEFINITION 
wrong.  It's the API Linux has, therefore it's what busybox should be 
primarily using.

> Rich

Rob
-- 
Never bet against the cheap plastic solution.