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

[Robert Schweikert]

>From an application point of view certification to a subset is less
important, however what we would need is a way to differentiate the
installed packages. Since we and probably others do not use RPM the
dependency theory is broken.

What if lsb-version would return different values depending on the LSB
components installed. For example on a server that does not have the GUI
components installed lsb-version could return "3.2 Core" while on a
desktop system with the full installation it could return "3.2 All". The
LSB itself of course must give distribution vendors the option to break
the required LSB components into two packages.

Once a distribution is certified to LSB it implies Core and GUI are
available for install with this distribution. Certification to Core only
is not possible. However, the user has the option  to not install the
GUI part of the LSB. An application such as ours then has the
opportunity to test at install time to make sure the proper components
are there. If a user does not want to install the interactive part of
the product there is no need to install the GUI part of the LSB and we
can just test for "3.2 Core" or whatever the number may be.

Robert

On Tue, 2006-09-05 at 18:03 -0400, Ian Murdock wrote:
> 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
-- 
Robert Schweikert                   MAY THE SOURCE BE WITH YOU
(Robert.Schweikert at abaqus.com)                 LINUX
ABAQUS Inc.
Phone : 401-727-4200
FAX : 401-727-4208