?????: [PATCH] make id conform SUSv3 and Coreutils id - different approach

[Bernhard Reutner-Fischer]

On Tue, Sep 16, 2008 at 11:57:24AM +0200, walter harms wrote:
>
>
>Vladimir Dronnikov schrieb:
>> Hello, Walter!
>> 
>>>From here below the acronym "IMO" is meant in every statement.
>> 
>> CONFIG_DESKTOP controls whether these FEATUREs are visible and thus
>> configurable; FEATUREd are made the extensions which can be avoid in
>> favor of size. As busybox doc _still_ fortunately states, one of the
>> primary goals is to keep it small. Those features that are used quite
>> rarely should be FEARUREd.
>> 
>> `id -G` is surely the case since it is not `id` default behavior. Some
>> people would prefer to not use it (my case, I never used or even knew
>> this switch:) Moreover, to make it FEATUREd costs nothing at runtime,
>> and a little at download-time.
>> 
>> The rule of thumb is the following: A) if one implements a feature
>> which ADDS (and not FIXES a bug) a functionality to EXISTING applet it
>> should be FEATUREd; B) if one implements a new applet all lengthy code
>> that can be thrown without loosing the main functionality, should be
>> FEATUREd.
>> 
>> Time (and critisism of co-users;) will then make its destructive
>> action: some of FEATUREd will loose enclosing #defines, some will
>> retain.
>> 
>
>
>saving space is honorable but i was curios if we have a formal definition
>what *normal* behaver of bb tools is.

This is the normal (minimal) behaviour:
http://www.opengroup.org/onlinepubs/009695399/utilities/id.html

>                                      In this example id did not match the
>behaver of the gnu id adding -G in that case is a nobrainer as the
>default behaver is to show uid/guid/all_groups. (I never used -G myself).
>
>we should think a bit: (means: this is not a pressing problem)
>* Is having all SUSv1/2/3 options a default ?

Yes, it's a default. If a (mandatory) feature is not used or not
implemented in the GNU counterpart then FEATUREing it makes sense, if it
saves considerable space. Note that there were numerous objections to be
too fine-grained WRT the config. Patches which add one knob for each arg
of an applet will usually not be accepted.

>* Is default behaver of gnu tools a must ?

GNU compatibility is desired. See also docs/contributing, section
"Testing Guidelines", for example.
>
>We have now >200 applets. That means that fine tuning (applet by applet) is not
>the best anymore. That means we need to settle some standards that enables/disables
>a lot of features at once. meta features/topics what ever you will call them.

We already have such knobs, think LFS, IOCTL names, CLEAN_UP, GETOPT,
buffer allocation scheme, etc. You should be very careful to define a
*new* feature set to match enough applets in a sensible manner. The
DESKTOP thing, for example, is imo not a good idea.