James Richard Tyrer
tyrerj at acm.org
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