>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.
