[lsb-discuss] lsb version and the specdb ModCmd and ModLib tables

Wichmann, Mats D mats.d.wichmann at intel.com
Mon Oct 23 11:33:10 PDT 2006



	From: lsb-discuss-bounces at lists.freestandards.org
[mailto:lsb-discuss-bounces at lists.freestandards.org] On Behalf Of Camp,
TracyX E
	Sent: Monday, October 23, 2006 11:47 AM
	To: lsb-discuss at lists.freestandards.org
	Subject: [lsb-discuss] lsb version and the specdb ModCmd and
ModLib tables

	I've been working on fixing up various things about the lsb dev
environment that bug me.  As those that know me well can attest, it's
the little things that bug me and one of them is repeatability.  In this
context I would like to be able to produce an lsbcc binary that can tell
you what version of LSB it was built from and then correctly link
binaries for that version.  Please note I didn't claim 'correctly
produce' binaries.  This is just an incremental solution I'm seeking.


	For reasons of sanity and quality I think it would be best if
this was not dependant on forking lsbcc.c and specdb for each and every
LSB release (though that might and probably does happen for other
entirely legitimate reasons).


	There are actually two parts of this issue, one of them is at a
header level (what interfaces, constants, macros and associated ABI
information are allowed in this LSB version?) and the other is at a
larger grained lsbcc link fixup level (what shared libs are allowed in
this LSB version?).  It is this latter problem I would like to address


	From looking at the specdb it appears that the ModCmd and ModLib
tables might be the place to add the missing lsb version information so
that lsbcc would know what to link shared for a given LSB version.  

 why not directly in the Module, Command and Library tables?


	I'm thinking of a schema change that would add two columns to
each table, one called 'LSB_Version_Appeared', and another called


	Since I'm new around here I'd probably populate the current
contents of specdb with '3.0' for all things not desktop and '3.1' for
all things desktop as the appeared version and provide a magic value for
the its-never-been-removed version.


for libraries at least, we do have better information than that but it's

not a terrible approximation in terms of what we "care" about.

	To complete the picture, I would then at build-time use a
build-time supplied LSB version number to generate the currently in-line
tables of LSB shared libs in lsbcc from the specdb.


	Upside: one less change to forget when adding a new lib to LSB,
one small step towards complete LSB version data in the specdb, and one
less thing that bugs me.  It might also be possible to pre-flight new
libs in the production DB w/o perturbing the current LSB version builds.


	Downside: Uncertain: would this collide with other work going on
someplace?  Libtodb would need another update and command line parameter
to insert the records. 


There's a large list of scripts that know something about the schema - 

see email from Vladimir Rubanov from earlier this month in this list's


dbadmin (its own project in the version control sense) certainly ought

know about such a change.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20061023/89caeb52/attachment.htm 

More information about the lsb-discuss mailing list