James Carlson wrote:

>> 3) <sys/queue.h> should never have been delivered in SUNWhea without a
>> supporting ARC case.  (But then neither should have sys/list.h.)
>>     
>
> I disagree with that assertion.  The contents of SUNWhea is not itself a
> documented interface -- in other words, what determines stability level
> is system documentation (man pages), and not what package delivers
> something or where it appears in the file system.
>
> We have historically shipped a mix of public and private interfaces via
> SUNWhea.  Long ago, I filed a CR (forget the number) that suggested
> breaking up SUNWhea (and the SUNWarc* and perhaps other) package into
> public and private bits, so that we could install only public interfaces
> by default, and exclude private ones from accidental discovery.
> (Obviously, users who need to can always install the private packages;
> we'd still ship them -- perhaps with even more things included -- but
> just not install by default.)
>
> Think of it as linker mapfiles for packaging.  The idea, unfortunately,
> went nowhere.  Too many people were either skeptical of the utility of
> breaking up SUNWhea or of the value of trying to segregate private
> interfaces better.
>
>   
I'm not of the opinion that breaking up SUNWhea into smaller packages is 
useful.  I *am* of the opinion that headers which are Project Private, 
or possibly Consolidation Private, should not be packaged at all.  (I'd 
probably grant a special exception for Consolidation Private interfaces 
which are *intended* for public consumption at some future date, but 
even that could probably just as easily be dealt with by a future push 
after ARC approves the interfaces for public consumption.)

I suppose at one point having those headers on the system was useful for 
debugging back when people had to manually work out structures in adb.  
These days with CTF they are completely unnecessary.  Whenever I easily 
I can, I remove project private (especially *driver private!*) headers 
from packaging.

    -- Garrett

Reply via email to