[lsb-discuss] LSB conference call agenda (Tuesday, July 11, 11am ET)

[Wichmann, Mats D]

No point in not doing a little bit of discussion of
some of these topics on the list, as well: 

>* LSB runtime tests: Same question here. How does this fit into the
>new certification system (I'll provide an overview of what we have
>today)? How is the testkit more than just a bundle of
>largely independent packages? How do we avoid situations like this:
>
>    1. A bunch of output was generated that made no sense to 
>    me given the context of the testkit, e.g., "when this package
>    finishes installing,  you should run /opt/lsb/xyz". These are 
>    undoubtedly postinst scripts from the test packages.

This is very much an artifact of bundling things which were
"designed" (sic) to each be handled separately, and each of
those trying to be helpful in a standalone way.  If testing is
to migrate to a model of everything installs (and maybe runs - 
I'm starting to look at Jiri's script again) with a single 
command, I agree some of these concepts don't make sense.
The design of good packages should always accommodate the
installation possibly being initated by another tool, and
quite possibly by one that is non-interactive in nature, so
a lot of output messages is not really good design (well,
this is the rpm model anyway; Debian packages seem to produce
a lot more output as a matter of course)

>    2. It asked me to type the root password at least 18 times.

The lsb-runtime-test guys wanted to avoid another dependency on
a non-LSB thing that was required to *run* the tests, but not
required for conformance - in this case expect or some similar
functionality that could save the initially entered root password
and feed it as input to other queries.  As you know this can't
just be done with "ordinary" shell scripting...  and also, this
is just a technical problem, there's gotta be a way to solve it.

Add #3: it's a pain in the butt that having completed all the 
tests, there are something like 8-10 journal files that have to
be gathered for examination and submission, each in their own 
path, and about half of those helpfully bearing the same basename
('journal'), and many of them with a variable dirname 
(...../0001e on first run, ...../0002e on the second, etc.) 
so it's tricky to just write a script that gathers them all in
one place.

>I doubt we'll have time to get to all of this in the hour we have,
>but if not, we'll continue the discussion next week.

At least some of us will be absent next week because of the
Desktop Developers' Conference in Ottawa.