[lsb-discuss] lsb version and the specdb ModCmd and ModLibtables
rajesh.banginwar at intel.com
Fri Nov 3 09:26:20 PST 2006
>So I would like to step back with the existing versioning
>proposals for the
>time being. Please keep your solution for your current needs
>(as if this
>discussion did not happen). I hope to be back some day later after we
>investigate the topic in detail globally for the entire DB.
If we really plan on having this done for LSB 3.2 (May 2007), we should
put some timeline for this to happen. Say, something like the DB schema
can not be changed after LSB f/f or we at least have a final proposal by
>From: Camp, TracyX E [mailto:tracyx.e.camp at intel.com]
>Sent: Wednesday, November 01, 2006 7:22 PM
>To: Vladimir Rubanov
>Cc: lsb-discuss at lists.freestandards.org
>Subject: RE: [lsb-discuss] lsb version and the specdb ModCmd and
>>The issue with LSB spec versioning in specdb is actually
>>broader than just
>>for modules and libraries. We need also to take into account
>>headers, constants, commands, etc. The specdb should be able
>>to answer which
>>of these things were in each LSB version, shouldn't it?
>Sure. But lsbcc doesn't care about that directly (though obviously it
>is an issue for producing a completely versionable build environment),
>so I wasn't trying to solve that problem...
>>The third solution is to use mixed concept - use separate tables for
>>Libraries and Modules (the number of these things is low so it is
>>affordable), while having fields for interfaces, etc. This may be not
>>beautiful with regard to uniform schema design but may be
>>quite a practical
>I'm willing to accept a uniformily of implementation argument for doing
>things your way. Could you send me a diff against the specdb for the
>modules and library tables? I'd like to get my lsbcc patch in and not
>have it tied to a larger specdb merge.
>>I appreciate any opinions regarding these alternatives.
>>BTW, does the linkage between Libraries and Architectures
>>affect your lsbcc
>>work (e.g. a library availability depends on architecture and this
>>dependence is specific for each LSB version)?
>Do we have situations like this today? That seems really broken if we
>lsb-discuss mailing list
>lsb-discuss at lists.freestandards.org
More information about the lsb-discuss