[lsb-discuss] LSB conference call (2011-04-27, 11am ET)

[Jeff Licquia]

On 04/27/2011 05:43 PM, Craig.Scott at csiro.au wrote:
> If the granularity/number of subcomponents is not relatively simple/small, ISV's may just revert to requiring lsb>=4.0 rather than bother working out the specifics of what their package really depends on. Personally, I wouldn't be surprised if for many it was just a question of whether or not GUI components are used and thus whether or not to add lsb-gui to the list of dependencies above lsb-core. That may just reflect the sort of packages I tend to work on though.

We've received criticism before because of just how much the "lsb" 
package pulls in.  Clearly, a split between "lsb-gui" and "lsb-core" 
would reduce that, but would it reduce that enough?  In particular, I've 
heard griping about GTK+ requiring Qt, and vice versa.

Part of the wisdom of subcomponents is that we'd be able to gather data 
about what people were actually using.  It wouldn't be so bad to specify 
a bunch of subcomponents, only to learn that the only ones actually used 
were "lsb-core" and "lsb-gui", say.  And if the opposite would be true, 
we'll learn that too.

> But a clearer situation is what would happen if you move things around later, by which I'm assuming you mean to rename the sub-components. If you do that, ISV's will be rather annoyed. The whole point of an ISV making use of the LSB is to not have to deal with precisely these sort of issues (things being renamed or changing between versions). The deprecation mechanism should really be reserved for things that were valid/current, but have since been phased out more so than correcting "things we got wrong". I'd suggest first understanding what didn't work with the previous attempt at making the LSB support a set of sub-components before having another go at this.

This is what always tends to hang us up: if we don't specify the 
"perfect" set of components, then we are stuck.  This kind of hesitation 
is what makes our current component model pretty much invisible to 
anyone outside of the workgroup.

Would it help both of your concerns if we provided a tool to report the 
minimal set of modules used by a binary?  We could include an option to 
format it like a Requires line in a spec file, for those people so 
inclined, or provide the list in ways that make it useful in an 
installer, product documentation, etc.