RE: RM: lsbappchk -- RoM; superseded by lsb-appchk2 and lsb-appchk3 and obsolete
>Mats can confirm, but it's my understanding that LSB 3.0 is
>not backward compatible with LSB 2.0, i.e., LSB 2 apps won't
>necessarily run on LSB 3 runtimes because some symbols were
>removed between LSB 2 and LSB 3.
There are some minor changes, and one very major one:
the C++ library was a complete swap-out, with a new
version number. The small number of libc symbols
removed are almost still in every glibc version.
Someone could certainly implement a 3.0 system
completely/only to the specification and then they
would not have the missing 2.0 symbols, but this is
not happening in practice.
However, the real issue is that LSBs of the past do
not *require* a distribution conforming to a certain
version to support any other version's applications,
so there's no *promise* of the backwards compatibility.
Technologically, with the addition of the older C++
library, and the required LSB linker, an LSB 3 system
ought to run LSB 2 apps. The model in the past was
to leave this possible, but at the discretion of the
distribution provider: if they wished to support
multiple LSB versions they could do so. As an example,
SuSE have certified systems to both 2.0 and 3.0
simultaneously. Thus, on any arbitrary system certified
to 3.0, you have no promise of running 2.0 apps unless
that distribution also has completed the 2.0 certification,
or less formally, provided a "2.0 compatibility kit" -
which is probably not too far different from how they
handle old-version support for their own distributions.
Reply to: