thiago at kde.org
Mon May 29 16:27:16 BST 2006
James Richard Tyrer wrote:
>> Menus aren't part of the LSB, therefore you're not allowed to have
>> them in LSB-compliant packages.
>And it is such total disconnects that result in people thinking that the
>LSB is useless.
Agreed. But this is going in circles: this thread started exactly to see
what other things are missing. Menus are one of them.
>> I'm sorry, you're missing the point here: LSB RPMs do not list
>> library dependencies at all. They list the LSB standard version they
>> are compliant to and that's all. The system is supposed to have all
>> the LSB libraries installed, with the correct sonames and the
>> correct symbols, with need to change anything in the dynamic loader's
>This appears to me to be totally unrealistic. Linux is about the
>ability to constantly upgrade the system and this would put an end to
As long as the upgrade is binary- and behaviour-compatible, that won't
break the LSB compliance.
Binary-compatibility here doesn't mean there are no other exported
symbols -- in fact, even in Qt 4.1.0, which was standardised, you're
going to find exported symbols that are not part of the LSB
specification. You're just not supposed to pretend they are not there.
When you upgrade to Qt 4.2.0, binary- and behaviour-compatibility won't be
broken, because we'll guarantee that. But it also means you cannot use
any of the new features of Qt 4.2.0 in an LSB 3.1 Desktop-compliant
>This makes one wonder about the binary incompatibilities in GNOME 2.14.
> How does the LSB deal with this? Specifically: GLib 2.8.x vs. 2.10.x
>and GTK+ 2.8.13 vs >= 2.8.14. Is this an issue, or did GNOME just make
>a big mistake that they need to correct?
I'm not sure you're grasping correctly what binary (in)compatibility is,
judging by your comments.
If we go down to the lowest level, binary compatibility is such that no
symbol that previously existed and was public ceases to exist and the
layout of any data structures remain the same. In C++ terms, it boils
down to not removing any public functions, not changing the order of
virtual functions and not changing the layout or inheritance of classes.
More details you can find in our Binary Compatibility docs on
>"It isn't the libraries that are really the issues ..."
>There are files other than libraries that apps need to access.
>Different directory tree arrangements do cause problems when trying to
>make a binary package run on all RPM based distros.
The LSB spec covers a few file paths and formats. Surely not all of them
and surely not the XDG ones.
But please, if you know more files that applications may need to access
and are not covered by LSB yet, let us know. This is exactly what this
thread is for.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com Trolltech AS
GPG: 0x6EF45358 | Sandakerveien 116,
E067 918B B660 DBD1 105C | NO-0402
966C 33F5 F005 6EF4 5358 | Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
More information about the kde-core-devel