[lsb-core] LSB database to provide more information
Wichmann, Mats D
mats.d.wichmann at intel.com
Fri Jun 2 15:57:34 PDT 2006
In line with some of the things talked about during
the meeting this week, and other issues I and others
have been thinking about, I'd like us to start thinking
about how we can use "the" LSB database, or possibly more
than one database (at some level maybe that's an
implementation detail whether it's one or more DBs) to
provide more information.
For example, the Interface table has a comment field;
I'd like to make sure that when an interface is described
in the database but is not part of the LSB that we have
a reason, or at least some kind of pointer. There should
be, although I haven't checked in detail, similar comment
fields in other tables, such as Library, Constant, etc.
This week I think I finished getting all of the POSIX 1003.2001
interfaces captured, and I'm moving towards having comments
on most of the ones that are not part of the LSB. The
comment includes the POSIX feature group and some kind of
status, like "not implemented by Linux kernel" or "in
glibc, we could add". I'd love to see this information
extended to other features beyond the POSIX interface set.
This way a newcomer (ISV, or whatever) browsing to find
out why s/he can't use interface X can actually find the
answer without having to depend on the memory of some
particular LSB developer who happens to recall the
discussion. Several of the table which should have a
comment field don't even have one, like Library and
Of course, the bit of work I did turned up some interesting
cases. Our current design is that there is only a single
base standard for any given interface. If the interface is
fully described in POSIX, POSIX is the standard. However,
if there's a difference from POSIX for a POSIX interface,
we list LSB as the reference standard instead. While on
one level this is correct, it also means if I query the
database for "show me all the interfaces from POSIX" I
don't actually get all of them, because I don't get the
ones with overrides in LSB. Perhaps there's a table
redesign or extension that could capture the additional bit.
Another thing I'd like to be able to do better is to have
a record of historical information. Right now each version
of the database is a unique snapshot in time. I can check
out from cvs, using tags defined for each release, one
database matching each LSB spec release, and presumably I
could do queries across these multiple databases to find
answers to questions like "show me the interfaces that are
in LSB 3.0 that were not in LSB 2.0", or "show me the
libraries that were in 2.0 but not in 1.3". This isn't
trivial (although I'm no database expert by a long shot),
as mysql has a concept of a current database and I don't
think you can use several at the same time easily.
So why can't I get that answer from "the" LSB database?
The only historical information we have now is the version
an interface was removed in; not when it was added.
Thirdly, the Interface table has an Itested column,
which is supposed to indicate whether a test exists for
it. As stated many times, we have no confidence that this
field is up to date, and it's also binary (well actually
tristate: "Yes, "No", or "Unknown") which means there's
no room for shades of grey. For example, I might want
to indicate that a particular interface has a functional
test, but we know it isn't complete. It also doesn't
tell me which test suite / test module (or whatever
granulariy we want) contains the test. Maybe there are
several - I could see a case where a portion of a
command is tested in the users&groups test module, and
a different aspect of the command is tested somewhere
else. We need to update / improve the information
relating to test coverage.
Fourth, and this is a topic that was touched on lightly
during today's meeting, is there a way for the database to
hold a pointer to the specification for an interface?
The spec currently has tables which, if you drill down,
will eventually take you to a reference to the *document*
that contains the spec. However, why couldn't I have a
web interface to the database which, while I'm browsing
for some interface, contains a link to the actual spec
for that function (at least for those where we have known
on-line html documents available).
There's probably a boatload of other things we could or
should do, but consider this as a starter list to seed
some discussion and proposals for how we could make the
LSB database(s) more useful.
lsb-core mailing list
lsb-core at lists.freestandards.org
More information about the lsb-discuss