Re: bugs just filed
Havoc Pennington writes:
> - the wording "--foo is not supported" seems to imply that an
> option must not be supported, though I doubt that was intended.
> I think wording such as "--foo is undefined" or "--foo is
> implementation-dependent" would be better.
I agree the wording could be clearer. The above sort of wording is
used where an option for a command is required by the SUS but at the
time of the writing of the specifiction was not supported by the
implementations of that command on Linux. In other words for people
porting to Linux they can't rely on that behaviour even if their app
is SUS compliant.
> - I don't understand why the LSB specifies interactive programs;
> those are not designed to be an ABI/API and are not a reasonable
> ABI/API. For example, I don't see how "su" can be used
> programatically (or if it can, only its noninteractive aspects
> should be described in the spec, IMO).
Some interactive programs are useful when developers want to give
users documentation on what to do when some manual configuration or
repairing is required.
> I did file a bug on one egregious example, "patch --debug" makes no
> sense whatsoever as part of an API/ABI spec, IMO. It's not like an ISV
> app should or could use that option, so why is it required for LSB
> compliance?
I agree this option didn't need to have been included. In general I
think that including options beyond what is required by SUS is better
as writing scripts can be a lot easier when you don't have to
constrain yourself to SUS only options. From a distribution
implementation point of view the options that were included with the
commands were a subset that existed on most distributions (except in
cases where implementations of a given command were so different
between distributions that the one that was seen as best was chosen).
Regards,
Chris
--
cyeoh@au.ibm.com
IBM OzLabs Linux Development Group
Canberra, Australia
Reply to: