[lsb-discuss] Modularization design proposal

Craig Scott audiofanatic at gmail.com
Tue Apr 3 23:30:24 UTC 2012

On 04/04/2012 08:41 AM, Robert Schweikert wrote:
>> A thought about lsb-release - will it make sense to request submodule
>> without specifying its module name? I.e.,
>> lsb-release -p LSB-Toolkit-Qt
>> instead of
>> lsb-release -p LSB-Desktop:LSB-Toolkit-Qt
>> (or add another option for this possibility)?
> I thought about this but discarded the idea for the following reason:
> I think we need to have these queries be explicit and "force" people 
> to think about what they require. For example when someone queries 
> LSB-Toolkit-Qt only it is implied that they get any basic Desktop 
> stuff that Qt may depend on, however this is not expressed clearly in 
> the query and thus may be forgotten. Therefore, the other stuff that 
> gets pulled in is a surprise. Using the long query makes people think 
> about this stuff (hopefully).

I think lsb-release needs to support both long and short forms. If only 
one is supported, I'd vote for the short form since it would mean 
developers don't need to change anything if a sub-module moves to a 
different parent module (eg deprecated or trial use modules, as already 
pointed out).

>> In the example with trial-use LSB-Ruby it is pointed that submodule name
>> doesn't change when moving from TrialUse to 'usual' module. However,
>> users of lsb-release still will have to switch from
>> "LSB-TrialUse:LSB-Ruby" to "LSB-Languages:LSB-Ruby" or even to perform
>> both requests to check if LSB_Ruby is provided by the system.
> Correct this may provide sufficient weight to implementing a "short 
> query", i.e. lsb-release -p LSB-Ruby and make the tool find it whether 
> it is in TrialUse or Languages. That said I am not convinced this 
> outweighs the "hidden surprise" baggage outlined above.

I don't think we need to be worried about the"surprise" factor. 
Developers are already expected to understand the basics of the 
structure of the LSB modules when they define their package 
dependencies. In the past, the advice has simply been to depend on 
"lsb", which pulled everything in anyway. The "surprise" factor would be 
something that would be realised once (and most likely fairly quickly), 
so it isn't a particularly dangerous or onerous, whereas changing what 
the package depends on has implications for end users when packages are 
released. As an example, say devs roll out an update, but there is 
potential for older distros to not have support for changed submodule 
parents, so an update might result in broken dependencies just because 
the LSB changed its module hierarchy - if I'm thinking clearly enough 
pre-caffeine. ;)

Craig Scott
Melbourne, Australia

More information about the lsb-discuss mailing list