LSB summit

[Thiago Macieira]

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
>>  configuration.
>
>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
> that.

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 
application.

>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 
developer.kde.org.

>"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
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060529/487f5118/attachment.sig>