[lsb-discuss] deprecation/compatibility: Discussion of possible redesign of lsbcc and checkers

Wichmann, Mats D mats.d.wichmann at intel.com
Thu Sep 14 03:24:23 PDT 2006


This is not a new idea, but seems like it's becoming
more important as we worry more about multiple-version
compatibility issues in LSB.

I kicked this around with Jeff yesterday, let's see
if I can capture the essence here.

When we've discussed the possibility of a new deprecation
policy, I've been somewhat concerned, but it finally
dawns on me that we actually have two layers:

1) the binary interface - the ABI
2) the source interface - the API

LSB is an ABI standard, but along the way we effectively
specify the API that is available.  It's the former,
the ABI, where the very conservative deprecation policy
needs to apply.  I can easily conceive of interfaces that
should leave the latter more quickly, in particular 
this should happen in advance of interfaces vanishing
from the binary standard [that is, new programs targeting
the latest standard are not allowed to use interfaces,
but runtimes must still provide them to run older programs].

Specific example: there are POSIX interfaces which have
been deprecated for the past six years and are now about
to be dropped from the latest revision (2007). When
LSB moves to align with that POSIX version, we need to
start moving those interfaces out of the API, but
they can stay in the ABI much longer.

In order to do this and other things we've talked about,
it is necessary for systems to be able to support building
using differing API sets to target different ABIs, and
for the checkers to be able to check against multiple
versions.

Again, an example:  if I'm operating in a world where
LSB 4.0 is the most current, but I determine that the
"highest common denominator" is LSB 3.1, I need to be
able to build for that target, and check that I met
that target.

This can be done now by installing the correct version of
the packages, certainly.  The downside is it does not
give the ability to target a different version with a different
piece of code without moving the packages to a different
version.  I'd rather be able to say something like

lsbappchk --lsb-version=3.1 foo

Which also has the advantage of being able to speculatively
examine a program - "I built for 3.2, but would this have
passed as a 3.1 app?" without doing checker uninstall/reinstalls.

For this to be possible, the checkers and build tools would
need to be able to understand multiple library/interface sets.
What currently happens for the checkers is that the data is
pulled from the specification database, munged into a C
source file that populates various structures, and compiled
into the application.  It doesn't seem like it would be
terribly difficult to instead generate the data in some
external data file in a parseable format, and do so for 
multiple versions of the LSB, such that the checkers can 
select the set of data files for the requested LSB version.

lsbcc is a slightly different case, as it's paired with
"stub libraries".  However, it should be possible to have
multiple sets of the stubs (and possibly matching headers),
at least at a first think.  It may turn out that this
sort of "cross-compile" - targeting a different LSB on
build - may not be a good idea.  lsb-buildenv should be
a much easier case: although it's space-consuming, you can
just set up a buildenv for each LSB version you have an
interest in targeting.

Any thoughts on all of this?




More information about the lsb-discuss mailing list