[Lsb-infrastructure] headers: next steps

Wichmann, Mats D mats.d.wichmann at intel.com
Tue Apr 15 07:20:02 PDT 2008


> I think we can simply drop all things withdrawn before 3.0. In some
> places we already drop some types of this kind (since inconsistencies
> there led to incorrect headers).

Drop as in clean from database, or drop as in don't generate into
headers?
For the latter, I don't believe there's any real reason to attempt
LSB 2.0 support and anything before that certainly it's okay.

>> I'd still have a preference to leave out any
>> 
>> #if __LSB_VERSION__ >= 10
>> 
>> but that's not a show-stopper for me.

> If we agree to drop all things withdrawn before 3.0, maybe it would be
> reasonable to print such comparisons only for LSB >=3.1?

that sounds good.

> Another important note - new mkheader doesn't take into account
> Csrconly field (previously all Constants with Csrconly='Yes' went to
> headers not regarding ACappearedin/ACwithdrawnin values). However,
> not all of such constants are marked as 'appeared', so they disappear
> after regeneration (they can be simply observed in diff). We should
> decide which of them we really need.

the "bzr diff" in build_env/headers is 2,544,334 characters long.
Is there another way to see these than looking at the diffs?


More information about the lsb-infrastructure mailing list