[lsb-discuss] Minutes for July 11 LSB call

[Jeff Licquia]

Despite having no agenda, we did get some good work done on the call
today.  I'll summarize the discussions; most likely, I'll miss some
important nuance, so please follow up with corrections where necessary.

1.  Qt 4

Jesper from TrollTech was on the line, and several issues surrounding Qt
4 were discussed.  Jesper reports that, after some time off, the test
suite is moving forward again.  Additionally, apps are starting to use
Qt 4, which increases the urgency for requiring it in the LSB.

There was some discussion regarding concerns with Qt 4 binary
compatibility; these had been raised on the list earlier.  Jesper
believes he has a solution.

Accessibility was also discussed.  George Kraft brought up his concerns
that the Qt a11y efforts were a little confusing; porting the Windows
iAccessible2 API to Linux makes no sense, as iAccessible2 is itself a
port of ATSPI to Windows.  Jesper will get Harald at TrollTech and
George talking about this, as he isn't involved with a11y.

Finally, we discussed "the RHEL3 problem": if RHEL4 and SuSE 9 can't
certify to LSB 3.2 because of Qt 4, then apps may find themselves having
to choose between supporting these distributions or using other
essential enhancements in LSB 3.2.  It seems this may be something to
work out between TrollTech and the relevant distributions.

2.  Perl and Python.

Mostly a status update.  The ISV survey was discussed, as well as the
presence of early drafts of the specs and appchk tools for each.  The
possibility was brought up that Perl and Python could become optional
for 3.2, and that this might be enough if we provided appbat RPMs for
lsb-perl and lsb-python that implemented the optional specs.

3.  dlopen() and plugins.

Robert brought up the problem of testing plugins.  There are two aspects
to this.

First, the tools don't work with dynamic libraries well in general.
It's easy to forget one or two, and since -D is not recursive, it's not
as helpful as it could be.  A few solutions were discussed: adding a
--recursive flag that works with -D, allowing a list of libraries in a
flat file, or even a "project specification" file which could be written
by appchk and updated by the user to catch missing libraries.  As a good
short-term solution, appchk should warn the developer if it detects
dlopen() use in the program being tested.

Second, plugins often leave symbols hanging that are intended to be met
within the program itself.  This is particularly a problem with popular
plugin ABIs, such as Mozilla's; it's impossible to certify a
LSB-compliant Mozilla plugin, such as those shipped by Adobe and Real,
without pulling the Mozilla ABI into the LSB, or without shipping
Mozilla with the app, neither of which is an appropriate solution.

I proposed that we allow something like a "LSB Plugin Certification",
where dynamic libraries can be allowed to document which symbols they
expect to be provided by the underlying app, and thus are "excepted"
from failing appchk for those.  This seemed to meet with approval
(though I might be biased).  Obviously, some things need to be fleshed
out before this can be real, such as the nature of the documentation
needed and whether we can use "common-sense" groupings like "the Mozilla
2.0 Plugin ABI" as substitutes or shorthand for full function call
lists.

4.  Certification system

George asked whether our certification system allowed people to delve
into the specifics of a particular certification, such as journals,
lists of waivers used, etc.  I described the current (unsatisfactory)
situation with the cert system, and mentioned that the ISPRAS folks are
reportedly working on a replacement; no details regarding timeline were
available.