[lsb-discuss] LSB 3.1 Certification

Banginwar, Rajesh rajesh.banginwar at intel.com
Wed Jun 14 16:23:03 PDT 2006

Now that we know there are going to be some installs where "desktop"
components may not be involved, we should think about a second
certification. I still think we should match "Certification" = "lsb
package" model. LSB 3.1 matches to lsb provide; LSB Base 3.1 matches to
lsb-base provide etc. I used the name Base here to refer to Core + C++
(don't care if we choose some other name). 

All LSB certified distros will be automatically certified to LSB Base.
So any application requiring LSB should just work on LSB and will not on
LSB Base. We should also remember that network connectivity can not be
guaranteed and hence we can't rely on the package manager to do the
"right thing" and pull down missing pieces. For applications (read ISV)
focused on Europe and North America for example this is not an issue...
And we do not have any representation from emerging markets where this
typically will be an issue.



> -----Original Message-----
> From: lsb-discuss-bounces at lists.freestandards.org [mailto:lsb-discuss-
> bounces at lists.freestandards.org] On Behalf Of Ian Murdock
> Sent: Wednesday, June 14, 2006 2:39 PM
> To: Irina Boverman
> Cc: lsb-discuss at lists.freestandards.org
> Subject: Re: [lsb-discuss] LSB 3.1 Certification
> 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
> > core/c++ and desktop. Is this still being considered? If yes, will
> > be available for 3.1 or only future certifications?
> The main discussion at the f2f centered around making it possible for
> compliant distros to install only the minimum set of LSB modules
> by an application. So, if an LSB compliant application didn't
> use the desktop component, the LSB shouldn't require it to be
> 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
> ends up pulling in the entire LSB. The reason is as follows: As we
> going down the two certification path for 3.1 (i.e., having separate
> and desktop certifications), the feedback we got was that having more
> one certification was confusing. I've been a pretty strong proponent
> of having a 1-to-1 relationship between certifications and
> 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
> 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
> I
> used to be. While there's clearly demand from the distros to provide
> applications to require less than the full LSB, I'm not sure
> that from a branding perspecitive (i.e., having multiple
> certifications) is confusing or useful. I'm leaning toward confusing
> Thoughts? This is actually a great opportunity to follow up on the f2f
> and get into that "ongoing conversation" I talked so much about then.
> > Where can I find transcripts of weekly meetings?
> I'll typically post minutes within a day or so of the meeting, though
> traveling this week and am a bit behind on the writeup. We'll also be
> recording the calls (hopefully starting in a few weeks) so you'll be
> to listen in directly.
> -ian
> --
> Ian Murdock
> 317-863-2590
> http://ianmurdock.com/
> "Don't look back--something might be gaining on you." --Satchel Paige
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/lsb-discuss

More information about the lsb-discuss mailing list