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

[Robert Schweikert]

On 04/27/2011 05:43 PM, Craig.Scott at csiro.au wrote:
>  From the meeting minutes:
>
> Jeff: So the concensus on submodules seems to be ISV won't care (in the sense they can pick whatever level of granularity works for them) and it may actually be easier for distros
> Alan: They're going to care with respect to how much trouble it becomes to describe things
> Jeff: Do you think more modules/submodules is more trouble for an ISV?
> Alan: No, if we break it down right
> Robert: We can't be afraid of getting things wrong. Our infrastructure has to be robust enough that we can move things around easily
> Jeff: But will it be easy to move things? How will an ISV handle it if a module moves?
> Robert: We'll have to have a transition period when things move, similar to the deprecation policy, so people can adapt.
>
>
> 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.
>
> 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.

Not necessarily, sub-components could retain the same name but be 
"promoted" to components, or become a sub-component of a different 
component. Thus, "lsb-X" my start out as a sub-component of "lsb-A" but 
after people started using things it becomes obvious that "lsb-X" should 
really be part of component "lsb-B" instead. We have to make things like 
this easy from an infrastructure point of view and define a policy that 
allows ISVs to transition.

Further, from an ISV perspective the division between sub-components and 
components should probably be completely transparent, meaning for an ISV 
they all look the same. An ISV would specify "Requires: lsb-gtk" or 
check "Is lsb-gtk installed?". That lsb-gtk is from an organizational 
point of view a sub-component of "lsb-gui" is therefore irrelevant.

Sub-components as such would only be visible for an ISV if there were 
"namespaces" such as "Requires: lsb-gui::lsb-gtk". However, namespaces 
in this sense do not exist, thus for an ISV a component is more or less 
the same than a sub-component from a dependency point of view.

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

Well, change is inevitable. First we are not going to get it 100% 
"right", whatever "right" may mean, when we release the first iteration 
of modules. Second, from my experience a big part is how we deal with 
changes. If today we do it one way and tomorrow we do at different way 
without warning, compatibility, transition, then I agree with you. 
However, with proper messaging, transition periods etc. I am confident 
changes are tolerable to ISVs. Most changes in the module structure will 
be unnoticeable to ISVs anyway and only effect distros.

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

Lets state this as we need a policy that defines how such changes are 
handled. I agree we should not use the deprecation policy even if the 
new policy looks similar to the deprecation policy.

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

There was no previous attempt. We've been discussing this for a long 
time and might finally have a proposal that has a good chance at 
success. Time to get cracking and do something.

Robert

-- 
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead
rschweikert at novell.com
rschweikert at ca.ibm.com
781-464-8147