[lsb-discuss] Implementing version compatibility in LSB 4

[Wichmann, Mats D]

The time to talk about this is before it bites us.
So - now.

Promises have been made of a higher degree of
compatibility with earlier releases, LSB 4 will
be the first place we have to stop and think about
how that will be presented.

===
Here's a very specific question:

The promise is, if I've built a binary for
LSB 3.x, it will run on LSB 4.0.  Let's say
we've decided to uplift glibc to contain the
2.4 symbols, and the binary contains a reference
to sys_errlist.  The default symbol version for
sys_errlist wiill be GLIBC_2.4, but my LSB 3
conforming binary will be bound to the then
current symbol version - that would be GLIBC_2.2.5
on amd64, just to pick one architecture.
For this to work, the requirement must be that
glibc on an LSB 4 system contains both symbol
versions.   Of course all glibc versions maintain
the old symbols as a matter of course, but that
has not been an LSB requirement in the past.

Now the question is, how do we reflect that requirement?

1. We could simply list both symbol versions as
requirements in the same table.

2. We could list the "backwards compatibility interfaces"
in a separate table, or set of tables.

3. We could do both (deprecated interfaces are currently
handled this way: 

13-3. libc - System Calls Function Interfaces
13-4. libc - System Calls Deprecated Function Interfaces

seen at:

http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core
-generic/libc.html#TBL-LIBC-SYSTE-INTS
http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core
-generic/libc.html#TBL-LIBC-SYSTE-DEPINTS

4. We could do it all by reference; instead of keeping
any of the 3.x-specific information inline, we insert
a blanket statement that an LSB 4.0 conforming system
must also support all the requirements of LSB 3.x.


Jeff pointed out in an earlier conversation that #4 has
a disadvantage if something is changing state, for
example an interface becomes deprecated in LSB 4; then
you have to do a "copy on write" operation instead of
a straight reference, instead you must say "... all
the requirements of LSB 3 except..." and then enumerate
those.




Let me note that the delta would not be very large if
it were not for one issue:  the change of four LSB
architectures from 64-bit to 128-bit long doubles
as of glibc 2.4; this has an effect on perhaps 100
interfaces, not just math interfaces but also interfaces
that know how to access numbers such as printf and scanf.
===

At a more general question, what do we do with libraries
that are candidates for uplift, which do *not* do
symbol versioning.  In many cases the name of the DSO
has not changed but small to large changes may have
taken place in the library (gtk family, for example).

What do we do with things like formats?  We specify a
very old rpm file format, and there's a desire to move
to a current version; would LSB 4 have to explicitly
call out *both* formats as required?

And what do we do about tests? In the case of an interface
that has changed, do we have to code a test which
tests *both* required versions of the interface (that is,
beyond the "existence check" of lsblibchk)?  Or is it
better to plan on running that LSB 3.2 test suite on
LSB 4.0 systems as part of the conformance process?


Well, I guess that's enough to get the discussion started.

-- mats