LSB summit

James Richard Tyrer tyrerj at
Mon May 29 03:07:02 BST 2006

Thiago Macieira wrote:
> James Richard Tyrer wrote:
>> The most important thing, IMHO, is the need to facilitate the
>> installation of third party applications -- that various distros need to
>> be standardized to the point that only two binary packages are needed (a
>> RPM and a DEB) -- that presumes that the correct versions of the
>> supporting libraries are installed.  The LSB specified RPM binaries so
>> only the RPM issue would be relevant.
> Isn't this exactly what LSB has been doing for years? With one, single 
> package (an RPM), you can install a program in all LSB-compliant distros.

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: 

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.

>> There is the secondary issue that RPMs do not have to specify the
>> minimum dependent libraries by version number (they can use a package
>> name and version number instead).  This is also a problem for third
>> party applications which can not be expected to have knowledge of the
>> names of a distros 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.

> An LSB 3.1 Desktop application will not install/run on a non-LSB compliant 
> system. If it is compliant, however, the minimum versions are installed.

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


More information about the kde-core-devel mailing list