[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RM: lsbappchk -- RoM; superseded by lsb-appchk2 and lsb-appchk3 and obsolete

"Ian Murdock" writes...

> That's fine, but the only distro I see anyone targeting anymore in the
> list of LSB 2.0 certified distros is SLES 9, and that's LSB 3.0 certified
> as well.

I was thinking of application developers that might want to build applications 
that would work on things as old as RHEL 3 when I wrote that, but checking the 
certifications at


it looks like we'd have to support back to LSB 1.3 in order to cover that :(
There are a couple of 2.0 certs in there, but since 2.0 was so short lived not 
too many I guess.

> 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 

> (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?

> leads us to strongly discourage anyone from targeting LSB 2.

Sure. But I don't want to pull the rug out on the older versions yet either. 
LSB 1.3 is old enough that I felt OK asking for the 1.x lsbappchk to be 
removed from the archive, but IMO 2.0 isn't quite old enough yet.

Matt Taggart

Reply to: