[lsb-discuss] LSB 3.1 Certification

[Wichmann, Mats D]

>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.

I think the basic situation is this:

If you're LSB 3.1 certified to the current requirements - everything -
you have by definition also met the requirements of any subset of
"everything".

As part of "everything" we require the package manager to provide, 
and the lsb_release command to also provide, lsb=3.1.

We do not have anything that precisely describes the subset of
(core && c++) but we could interpret lsb-core-{arch} as meaning
that.  The lsb-core module still requires this to be provided,
and since that's part of what was sent to ISO, it was not removed
in the full 3.1 publication.

This is not an ideal solution (we'd like lsb-core==iso, not
lsb-core==iso + some_other_stuff), but it's the one thing we
could pursue in the short term.

This would mean distributions would have to make sure *not*
to provide "lsb" if they have only the subset installed, and
to make sure that they always provide "lsb-core".  We don't
have tests for this, in the past the provides have been something
you sign off on on the certification application rather than
some thing that is explicitly tested for.

And a subset install would have to make sure it still passes
lsb-runtime-test and qmtest_libstdcpp, as well as some 
appropriately modified lsblibchk that checks for the subset -
we went away from that but it wouldn't be terribly hard to
restore; and we've have to make sure lsbappchk can confirm
that a particular application only uses the subset functionality.
I think there's an lsbpkgchk impact as well, but these are
technical details at our end, not a big deal.

Is this avenue worth pursuing, or is it too ugly?