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

List:       kde-core-devel
Subject:    Re: LSB summit
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2006-05-28 5:33:16
Message-ID: 4479361C.20702 () acm ! org
[Download RAW message or body]

Aaron J. Seigo wrote:
> hi all...
> 
> there is an upcoming LSB summit[1] on the 1st and 2nd of june. i will be in 
> attendance representing kde; waldo will also be there (though he's officially 
> wearing his intel / osdl / fd.o assortment of hats ;).
> 
> there are a number of issues of great relevance to KDE on the agenda, as it 
> has a very concentrated on effort on the desktop side of the LSB and making 
> the LSB actually useful to ISVs, OSVs, etc...
> 
> now ... i really don't care if you think the LSB is bullocks. i know many 
> people share that sentiment and that's fine by me. but i'd like to avoid this 
> becoming a debate over the LSB or the FSG itself.

I suppose that I share the sentiment that LSB sucks (and it isn't a 
vacuum cleaner).  However, I have that opinion for a very specific 
reason which is my concern.

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.

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.

Linux is rapidly going the way of UNIX where the various distros are 
becoming more and more fragmented.  When I first heard of LSB, I 
presumed that it would help prevent this.  I was told that I was wrong. 
  IIUC, there is some hope that this will change.

-- 
JRT
[prev in list] [next in list] [prev in thread] [next in thread]