[OpenIndiana-discuss] e2fsprogs header file bug

[James Carlson]

Andrey N. Oktyabrski wrote:
> On 28.10.11 18:29, James Carlson wrote:
>> You might have an argument that e2fsprogs shouldn't include this header
>> file.  Most projects (for what it's worth) just toss in the kitchen sink
>> -- anything that's built is shipped, even if it's not normally useful
>> for anyone outside of the project.
> Thanks for detailed explanation, you are right. But if you don't want to
> give someone something, don't give it. Otherwise it is a cheese in a
> mousetrap.

If one were malicious, it'd be a way to catch people who write code
without reading the documentation.  :-/

> Perhaps, it is necessary to remove unusable headers from system?

Well, much luck in that.  Years ago at Sun, I filed a bug on it, and I
had lengthy discussions with some of the senior architects while trying
to find a way to address it.  I never really did get much agreement on
the issue.

What I wanted to do was to segregate the documented interfaces (i.e.,
the things people in other projects _should_ be #including) from the
undocumented ones (the things they should never #include) via packaging.
  That is, you'd have a "normal" /usr/include that gets installed, and a
set of "extra" packages containing /usr/include files that you "should
not" be using, but that have historically been shipped with the system.
 It seems like a simple idea, and possibly helpful to keep users on the
straight-and-narrow, but:

  - Many system headers have a wild mix of documented/public interfaces
    and undocumented/unusable ones.  You'd have to separate out these
    bits first into separate files, likely involving tens of thousands
    of lines of code churn.
  - At least at Sun, there were hundreds of obscure groups contributing
    code to ON all the time.  There was simply no feasible way to get
    all of them to stop contributing unusable bits to /usr/include, so
    even if you could do this, it'd be a one-off hack.  Eventually, new
    trash would appear.  There's no way to make it stay fixed.
  - Some third-party software (unfortunately!) relies on undocumented
    and only partially usable bits from /usr/include.  Since a lot of
    people rely on that code, cleansing /usr/include would have little
    effect -- real users will have to install the "naughty" package
    containing the "unusable" headers so that they can continue
    building the software they really want.  If everybody installs
    that, then the work of separating the bits was wasted.

I also tried removing headers that were utterly without merit, such as
/usr/include/net/af.h.  That doesn't do anything on Solaris, and never
did.  You'd be surprised and dismayed how much crapola like that is
strewn in /usr/include.  I spent months categorizing stuff, removing
garbage, and rewriting mistaken code throughout the system that actually
_used_ these _unusable_ headers, but never got to the point of
integrating the work.  I still have the diffs somewhere if someone wants
them.

I like cleanliness, so I wouldn't argue against someone making
improvements here, but I've been beaten down enough myself.  ;-}

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>