No subject

Jeff: So the concensus on submodules seems to be ISV won't care (in the sen=
se they can pick whatever level of granularity works for them) and it may a=
ctually 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 mo=
dule 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>=3D4.0 rather than bother working ou=
t the specifics of what their package really depends on. Personally, I woul=
dn'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 d=
ependencies above lsb-core. That may just reflect the sort of packages I te=
nd to work on though.

But a clearer situation is what would happen if you move things around late=
r, by which I'm assuming you mean to rename the sub-components. If you do t=
hat, 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 shou=
ld really be reserved for things that were valid/current, but have since be=
en phased out more so than correcting "things we got wrong". I'd suggest fi=
rst 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.

--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia