[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: LSB summit
From:       Thiago Macieira <thiago () kde ! org>
Date:       2006-05-29 7:16:00
Message-ID: 200605290916.09642.thiago () kde ! org
[Download RAW message or body]


James Richard Tyrer wrote:
>That is what we thought that it would do, but this is not the case.
>Have you installed OpenOffice 2.0.2?  See the directory:
>"RPMS/desktop-integration":
>
>	openoffice.org-debian-menus_2.0.2-3_all.deb
>	openoffice.org-freedesktop-menus-2.0.2-3.noarch.rpm
>	openoffice.org-mandriva-menus-2.0.2-3.noarch.rpm
>	openoffice.org-redhat-menus-2.0.2-3.noarch.rpm
>	openoffice.org-suse-menus-2.0.2-3.noarch.rpm
>
>One for Debian, one for the XDG standard and one each for the three
>major commercial distros.  This is the issue that I am talking about.
>Looking at the file lists for the last three packages (in KPackage) will
>give you some further insight into the issue.

As Waldo said, this is why standardising the XDG menu and probably other 
standards into the LSB is important. Menus aren't part of the LSB, 
therefore you're not allowed to have them in LSB-compliant packages.

>> Right. LSB RPMs use the LSB libraries. They don't need a minimum
>> version for each library: they just need the minimum LSB version.
>
>You missed my point.  Some RPMs list dependencies on other RPM packages
>not on the actual names of the libraries needed.  This makes them less
>than usable on other distros.

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.

There's no such thing as "minimum required version". For instance, Qt 4.1 
was standardised in LSB 3.1 Desktop -- that means its symbols and its 
behaviour was standardised. Any other library or version matching those 
requirements is considered LSB-compliant.

>It isn't the libraries that are really the issues since that can be
>addressed by installation systems (if actual library names are used).
>It is the fact that different distros have different directory tree
>layouts and install stuff in different locations (and it isn't just
>whether or not they use "opt").  This is the fragmentation problem. 

As I said above, the LSB libraries are found by the LSB dynamic loader. 
Applications do not have to worry about them.

>At 
>the current state of things, a third party application developer can NOT
>make an RPM that will install and work correctly on the desktop of all
>LSB compliant systems.  They can address it like OO.o has, but that
>'solution' only shows that the problem does exist.

Indeed. Hence Waldo's question to this list: what else is missing?

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

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]