[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