[lsb-discuss] lsb version and the specdb ModCmd and ModLibtables
vrub at ispras.ru
Wed Nov 1 05:27:06 PST 2006
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?
Your solution with 'LSBVersionLibs' table is very good at the libraries
local level. But creation of similar tables for the rest of artifacts will
greatly increase the size of specdb, and it won't be easy to maintain these
tables. So this solution is very good conceptually but faces technical
problems due to the large volume of data.
The solution we think of here at ISP RAS with adding additional columns
(appeared, withdrawn, was_excluded_in, was_optional_in) is a compromise
between concept and practice. It still solves the tasks that you mention
while saves DB space and simplifies DB schema. The drawback - it complicates
queries to retrieve information.
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
Finally, the last solution is to keep things as they are: maintain a
separate DB for each LSB version and add info about version history only for
those needs that become burning like for the lsbcc. This may be a good
solution for the time being. :)
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)?
From: Camp, TracyX E [mailto:tracyx.e.camp at intel.com]
Sent: Tuesday, October 31, 2006 9:24 PM
To: Vladimir Rubanov
Cc: lsb-discuss at lists.freestandards.org
Subject: RE: [lsb-discuss] lsb version and the specdb ModCmd and
I'm glad to hear that somebody is taking on the task of cleaning up the
I have specific concerns about your specific approach here with
versioning libraries and modules since a library may appear in at least
4 states in a given LSB release: 'not there', 'required', 'optional',
and 'withdrawn'. The point is to be able to reconstruct that state for
any given LSB version from the DB. Thus I took the approach of adding a
new join table that tracks this state independently from the specific
library tables (since this is a many to one relationship and I don't
like the idea of adding a lot of 'WHERE required_version >= $VERSION AND
withdrawn_version > $VERSION' statements everywhere.
Also simply adding four columns to each of these tables does not handle
the potential case of a library being optional then withdrawn and then
required in that order.
I'd be happy to discuss this particular technical issue with you some
more if you like. Please see the attachments to bug #1509 for the
details of the change I'm proposing.
More information about the lsb-discuss