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

Vladimir Rubanov vrub at ispras.ru
Thu Nov 2 07:45:32 PST 2006


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 versioning
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.

/Vladimir.


-----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
ModLibtables


>The issue with LSB spec versioning in specdb is actually 
>broader than just
>for modules and libraries. We need also to take into account 
>interfaces,
>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
>solution.


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
do.

T.





More information about the lsb-discuss mailing list