> Furthermore, the rest (Linpus, Mandriva, Sun Wah) are about to LSB
> 3.1 certify new versions.
Yeah, application developers who only care to support the very latest versions
of distros can just target 3.1.
> That, and the fact that LSB 2 is not compatible with LSB 3
They had different ABIs but a system could support both at the same time right?
I thought the whole point of a major version of the LSB is so you could break
the ABIs when needed (mainly when upstream does) and a runtime system could
support both ABIs at the same time by delivering both sets of libs. This would
allow application developers and users time to gradually transition. This is
particularly true in big Linux shops with bunches of applications, all their
apps won't be on the new version of the LSB right away. If people try hard and
there are good roadmaps, hopefully everyone moves around the same time, but
it's impossible to get _everything_ to line up perfectly, there are just too
many variables.
Maybe you mean LSB 2 applications are not compatible with LSB 3 runtimes (we
know that to be true with libstdc++ in particular, and probably other cases).
If the ABIs _are_ compatible going forward then they can just be minor LSB
versions right? Wouldn't that imply that LSB major revisions are _only_ for
ABI breaks? Unless maybe major revisions are also for marketing reasons?
If upstreams are good about versioning their libraries, you could probably
transition from one version to the next by just adding the new versioned
library (I can't remember how the LSB feels about that, maybe only at major
versions?). To deprecate the old version you'd need an LSB major version I
think.
> (whereas LSB 3 and higher will be backward compatible),
I don't understand what this means. Are you saying newer LSB applications will
be able to run on older LSB runtimes? If so how would that work?