Supporting multiple LSB runtimes

Hi lsb-discuss and lsb-futures,

AJ Towns and I had a discussion about how Debian is going to implement an LSB 
2.0 runtime. We had some thoughts that have implications for LSB upstream and 
other runtimes. Here's what we came up with.

Requirements
============
1.) Runtime implementations need to be able to support more than one
  version at a time to allow for applications that need the different
  versions. Example: LSB 1.2, 1.3 and 2.0
2.) Currently runtime support for a version of the LSB implies support
  for all previous versions, and applications can count on that.
  Example: you should be able to run a 1.2 application on a 1.3 system
3.) There may be a need to break the backward compatibility defined in
  #2, if so runtimes will need to be able support multiple versions.
  Example: LSB 3.0 breaks some ABIs and applications that require
  older versions will not work in a 3.0 only environment,
  implementations need to support pre-3.0 as well as post 3.0 runtimes
4.) Runtimes will have a need to deprecate support for versions of the
  LSB. Example: Distro has to support LSB 2.0, 2.1, and 2.2 and wants
  to drop support for 1.3
5.) LSB applications should be able to coexist. Example: App1 shouldn't
  have mutually exclusive dependencies with App2

Observations
============
* Due to #2, applications will need either a dependency on the keystone
  package or maybe a versioned dependency if they require a particular
  version. Examples: "Depends: lsb" or "Depends: lsb >= 1.3"
* Due to #3 and #1, the keystone packages for the different supported
  versions will need to have different names. Examples:
    lsb-1.3, lsb-2.0 or lsb, lsb2 or ...
* Due to #2 and the above, different keystone packages will provide
  support for different releases. Example:
    Package: lsb  Provides: 1.2, 1.3, 2.0, 2.1, 2.2
    Package: lsb3 Provides: 3.0
* In order to support depecation(#4), applications will need to
  explicitly depend on a version of the LSB, either via a versioned
  depend or depend on a different package name as above. Example:
    Depend: lsb >= 1.3
    Depend: lsb3
* Applications should never hardcode a versioned dependency.
  Example: any two of these could not be installed at the same time
    App1  Depend: lsb = 1.3.1
    App2  Depend: lsb = 1.3.3
    App3  Depend: lsb = 1.3.3-1 (distro version number)
* Some applications will be able to support multiple non-backward
  compatible LSB versions, like if they didn't depend on the particular
  ABI that broke. Example: Depend: lsb >= 1.3 | lsb3

Questions
=========
* How often will breaking the ABI happen?
   Can't be predicted but assumed >0
* How often should deprecation be allowed?
   Need feedback from the runtime and application providers
* How should the multiple keystone packages be named?
* What keystone package names should LSB applications depend on?

Potential Solutions
===================
A.) Only when the ABI needs to break.
    Package: lsb  supports: 1.2, 1.3, 2.0, 2.1, 2.2
    Package: lsb3 supports: 3.0
    Package: lsb3.1 supports: 3.1 (oops we broke it)
    Package: lsb4 supports: 4.0, 4.1 ...

B.) Every major version.
    Package: lsb  supports: 1.0, 1.1, 1.2, 1.3
    Package: lsb2 supports: 2.0, 2.1, 2.1, 2.2 ... 2.6
    Package: lsb3 supports: 3.0, 3.1 ...

C.) Every minor version.
    Package: lsb-1.1  supports: 1.1
    Package: lsb-1.2  supports: 1.2
    Package: lsb-1.3  supports: 1.3
    Package: lsb-2.0  supports: 2.0
    Package: lsb-2.1  supports: 2.1

(Note: The packages above may be real packages or implemented as virtual 
packages, the key is that they exist for applications to depend on.)

I would like to see these questions answered and a recommendations documented 
in the spec to help runtime and applications implementors do the right thing.

I think this needs to be done before releasing LSB 2.0.

Thanks,

-- 
Matt Taggart
[email protected]