Correct. When a commonly-needed package becomes "stable", a snapshot of its interface specification is taken, and added to the LSB. LSB applications can then rely on that interface being available. That might sound like a no-op, but the painstaking attention to detail involved in nailing down the interfaces of the LSB offers a lot of stability.
The problem is the LSB doesn't nail down the interfaces. It can't actually, if Wine has taught us anything it's that interfaces leak. The LSB library specifications are just lists of symbols. There's no attention paid to semantic breaks in behaviour, even though they are often what stops programs from working.
I'm not aware of e.g. an LSB-1.3 application that doesn't run properly on any system that supports LSB-1.3. Are you?
I'm not aware of any LSB applications at all, actually. But let's take RealPlayer for example. Let's pretend that Real had made it an LSB app.
Would that have saved it from being broken by NPTL. No. LSB doesn't specify (as far as I'm aware) that LSB apps must be linked against LinuxThreads.
Let's take XMMS. Let's pretend XMMS was shipped as an LSB app. Would that have stopped it from crashing on startup due to the addition of ARGB visuals to Xlib, a feature that was known to break old software but is being enabled anyway? No.
OK, so the Composite extension isn't enabled by default yet, but there is another env var for this: XLIB_SKIP_ARGB_VISUALS works like LD_ASSUME_KERNEL, ie it's an "unbreak me" switch. You have to know about it in order to use it. I talked to the X guys about this, they aren't interested in inverting the meaning of the switch (ie, making it a "please give me new features" switch) so it's likely when Composite is shipped it'll be in this form. NPTL all over again.
The LSB was supposed to provide a stable C++ ABI. In the end it stabilised one produced by no shipping compiler, and the distro vendors seem to be ignoring it as a result.
I used to be a big supported of the LSB. I really did think it was The Way Forward. But, these sorts of things keep happening and the LSB did nothing to stop them. In investigating *why* they kept happening I came to the conclusion that the LSB doesn't have enough power to really fulfil its mandate currently.
It needs, at minimum, the ability to specify details of implementation, for instance LSB should have specified that LinuxThreads not NPTL would continue to be used by default on all conforming implementations unless a PT_GNU_STACK style flag was present in the ELF headers. But this would have been overriding upstream policy which violates their constitution, therefore they couldn't/wouldn't do it. It should have specified that "." and ".." are always the first entries in a directory listing, but if it does (not sure, LSB references a lot of other specs) then Red Hat ignored it.
The transition to NPTL, like many other transitions in Linux's history, was painful, but that's exactly the kind of pain the LSB saves applications from.
Except it didn't. LSB does nothing to stop old apps from being linked to NPTL, unless there's some paragraph I missed in the spec that deals with it. Even if there is, LSB has been around for longer than NPTL and yet we still had to go through a painful transition which would imply it didn't work.
http://freedesktop.org/pipermail/xorg/2004-August/002326.html says "COMPOSITE is experimental, users of it should expect things to break." I believe that the COMPOSITE extension is not part of LSB, so any application using it is not LSB-conformant. Here again, applications that conform to the LSB are saved from the pain of unstable interfaces changing.
Ah no, the breakage doesn't work that way. The problem is that some apps contain different visual matching algorithms which get confused by the presence of the ARGB visuals. This is especially common in older GTK 1.2 apps which use Imlib, like XMMS, VMware or the Macromedia Flash plugin. These visuals are presented to the app even if it wasn't written to use them.
I do not know if it will affect Wine (probably not). It's like NPTL - the underlying behaviour of a system changed in a way that breaks programs.
IOW it's a semantic breaking change that the LSB does nothing about, and shows no signs of ever doing anything about.
That's ok. All we need is that they have a useful, working desktop specification. Mike, I get the feeling you want the LSB to be something it's not.
Well, yeah. You're right. I want it to provide a desktop platform that's competitive with Windows, but I don't think it ever will.
thanks -mike