"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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
