[lsb-discuss] lsb version and the specdb ModCmd and ModLibtables

Camp, TracyX E tracyx.e.camp at intel.com
Thu Nov 2 08:14:14 PST 2006

I could certainly see admitting this is a hard problem and simply coming
back to it later. I'm starting to believe doing nothing here might be
the right answer. I updated bug #1509 yesterday afternoon with that in
mind since the lsbcc patch introduces some code factorization that I
still really want.

Back on the topic of actually solving versioning.... I come from the era
of cheap and plentiful storage, so database size on its own doesn't
bother me in the least, but I'm not able to really judge the performance
and manageability tradeoffs.  I suppose that's why databases can be a
separate specialty.

Perhaps a good starting point would be to come up with a list of tricky
versioning situations.  This might be good stuff to put on the wiki and
then we can all think about solutions to the trickly versioning problems
or decide they really aren't problems.

Tracy Camp

>-----Original Message-----
>From: Vladimir Rubanov [mailto:vrub at ispras.ru] 
>Sent: Thursday, November 02, 2006 7:46 AM
>To: Camp, TracyX E
>Cc: lsb-discuss at lists.freestandards.org
>Subject: RE: [lsb-discuss] lsb version and the specdb ModCmd 
>and ModLibtables
>Tracy, I am still not sure which variant is better and I'm 
>even not sure if
>we included *the right* variant in the list (i.e. if we found 
>it at all). We
>are discovering more and more issues with introducing 
>versioning info in the
>db and there is no obvious solution. The problem seems to be 
>not simple. We
>need to decide what level of granularity we should address in 
>because the ultimate versioning would multiply DB contents unacceptably
>while all the partial variants have their inherent cons.
>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.
>-----Original Message-----
>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

More information about the lsb-discuss mailing list