[lsb-discuss] LSB Core certification, allow LSB apps to depend on less than full LSB

Ian Murdock imurdock at imurdock.com
Tue Sep 5 15:03:47 PDT 2006


Someone reminded me that we never closed the loop on the LSB f2f
discussion about certifying to something less than the full LSB:

Ian Murdock wrote:
> Hi Irina,
> 
> On 6/14/06, Irina Boverman <iboverma at redhat.com> wrote:
>> During f2f meeting it was suggested to have 2 or 3 certification types:
>> core/c++ and desktop. Is this still being considered? If yes, will this
>> be available for 3.1 or only future certifications?
> 
> The main discussion at the f2f centered around making it possible for LSB
> compliant distros to install only the minimum set of LSB modules needed
> by an application. So, if an LSB compliant application didn't
> use the desktop component, the LSB shouldn't require it to be installed.
> 
> This isn't currently how it works in LSB 3.1. LSB 3.1 says a compliant
> application must depend on a single package, "lsb", which when installed
> ends up pulling in the entire LSB. The reason is as follows: As we were
> going down the two certification path for 3.1 (i.e., having separate core
> and desktop certifications), the feedback we got was that having more than
> one certification was confusing. I've been a pretty strong proponent
> of having a 1-to-1 relationship between certifications and user-visible
> modules (i.e., the things a user can install, depend on, etc. with the
> package manager), and that's why we ended up making everything required.
> 
> There was pretty strong consensus at the f2f that we got it wrong, and
> that it should be possible for distros to install, say, only LSB
> Core if that's all the application needs, and to use the
> dependency mechanisms in the package systems to make things work.
> 
> Mea culpa.
> 
> So, we need to allow for this. Whether we can do this retroactively
> for LSB 3.1 or whether this is a 3.2 thing can be an open question.
> 
> The real question is whether the 1-to-1 relationship between certifications
> and user-visible modules is important. I'm less convinced about this than I
> used to be. While there's clearly demand from the distros to provide and
> applications to require less than the full LSB, I'm not sure articulating
> that from a branding perspecitive (i.e., having multiple
> certifications) is confusing or useful. I'm leaning toward confusing now.

After some discussion, we do not currently plan to add certification for
LSB Core or any other LSB subset, the main reason being potential market
confusion.

However, it is not a requirement currently that a compliant
runtime ship the entire runtime in its default configuration; so,
you can install just the Core or just the Core and C++ in the
default configuration and still be LSB compliant, so long as if an
LSB compliant application is installed, it is possible to install the
full LSB runtime (typically, this capability would be
provided via the automatic dependency mechanism of, e.g., APT or yum).

In LSB 3.1, compliant applications depend on a single metapackage called
"lsb", so an LSB compliant runtime should provide that metapackage and
provide all the required components when it gets installed. In LSB 3.2,
we'll allow applications to only depend on the subset of the LSB they
require (e.g., lsb-core). It's an open question whether or not we should
retroactively add this to LSB 3.1. (I'd welcome any discussion here.)

(Note that LSB 3.0 is roughly equivalent to LSB Core 3.1, and the
FSG still certifies products to 3.0, so there's always the option
to certify to LSB 3.0.)

-ian
-- 
Ian Murdock
317-863-2590
http://ianmurdock.com/

"Don't look back--something might be gaining on you." --Satchel Paige




More information about the lsb-discuss mailing list