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
http://www.freestandards.org/cert/certified.php
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
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?
> 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
taggart@debian.org
Reply to: