The Linux Foundation

 
MultiVersion

From The Linux Foundation

Revision as of 19:47, 24 April 2006 by ImportUser (Talk)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)

Contents

Multiple Version Support for LSB Runtimes

No released LSB specification has required a conforming implementation to support previous versions of the specification as a condition of conformance. There are also no current plans to add such a requirement, although interested parties are free to lobby for such a change. Beginning with LSB 2, this discussion refers to major versions of the specification, as minor versions do not introduce incompatible changes.

Of course, it may be desirable for an implementation to support applications developed for an earlier version of the specification, and the LSB also tries to make it possible for them to do so.

Packaging provides

The Packaging specification requires versioned package manager provides which can be used to check for the specific version of the LSB supported. These may coexist assuming the native package manager allows such coexsistence (
rpm
does). The
lsb_release
command, since LSB 2.0, is also able to provide multiple answers - the mechanism for this is documented in the Packaging specification.

LSB Linker

The LSB runtime linker is versioned matching each major LSB version. An implementation providing LSB 2 conformance must thus provide an
ld-lsb*.so.2
which must be used by LSB 2 conforming applications. Similarly, an implementation providing LSB 3 conformance must provide an
ld-lsb*.so.3
which must be used by LSB 3 conforming application. These may coexist, and provide the hook for the implementation to do different things for different versions of the LSB, if necessary.

Library Versioning

Required dynamic libraries are versioned, and some are also symbol-versioned. Major incompatible changes will typically change the library version, in which case there is no coexistence problem. For symbol-versioned libraries, if there are interface changes but no library version change, the implementation may choose to provide one library which fulfills the need of multiple versions of the LSB, or it may choose to provide separate libraries, in which case the LSB Linker is used to select which library is used at runtime.

Commands and Utilities

As the comments attached point out, something needs to be said here. Applications may query
lsb_release
for feature sets implied by particular LSB version/module combinations. However, it's not clear how an implementation can provide the Commmand/Utility behavior implied by multiple LSB versions if there are incompatibilities; unlike for program usage of libraries, there's no way for the implementation to point off to a backwards-compatibility set of utilities.

[[[MultiVersion]]/Comments User Comments] [[Include(MultiVersion/Comments)]]


[Article] [Discussion] [View source] [History]