LSB Teleconference notes from 1 June 2005

The LSB Workgroup met by teleconference on 1 June in
a special session, co-opting the slot normally used
for LSB Specification Authority. Present on the call
were: Mats Wichmann, Nick Stoughton, Gordon McFadden,
Rajesh Banginwar, Russ Herrold, Marvin Heffler, Mark
Brown, Mike Perry, Stew Benedict, Stuart Anderson,
Matt Taggart, Andrew Josey, Nilesh Jain, Jim Zemlin.
[I think there was one other, if you care to be
identified, please let me know]


The meeting focused entirely on moving the 3.0 specification
release forward, as it is currently blocked on several
bugs marked as "release blockers".

The largest category of these is bugs relating to
lsbinstall - lsbinstall itself is covered by several
bugs and there are some bugs against the system
initialization chapter that are affected by the
absence or presence of lsbinstall.  Most of the
discussion focused on lsbinstall, as a result.

The situation is as has been reported here several
times previously.  There are things an LSB package
cannot do that a package targeted at a specific
distribution can.  The LSB already intentionally
disallows things like package triggers, because it
would be hard to implement this in packages translated
to non-RPM formats.  The uncovered area is installation
of files and entries in files needed for proper operation
which need to go into paths not specified or disallowed
by the LSB (some of these are FHS requirements; and of
course FHS is included in LSB by reference). In some
cases it is known that these facilities are not
implemented consistently across distributions. 
lsbinstall provides a way to abstract this problem -
essentially it provides a shell-level API that can
be invoked by the post installation processing of
a package to make sure such a resource is set up
properly on the target system.

There is no disagreement that this is a required
feature; the disagreement is over whether it should
be mandated in LSB 3 or not. The three main concerns
against doing so are:
1. The specification and sample imeplementation are not
yet "cooked" - as the team digs further into it, new
issues and requirements are still being uncovered.
2. There is no industry precedent for it; distributions
would have to take up the LSB's spec and sample and
decide if they were willing to deploy it in LSB 3 systems.
3. It is the LSB's intent to propose the changes between
LSB 2.0.1 (which was balloted on by ISO) and LSB 3.0 and
propose them in the final resolution meeting to produce
the ISO specification; this is a new feature since then
and could have a negative effort on that process.

The concern against leaving it out of LSB 3 is:
1. There are known classes of applications that will
have a hard time certifying to LSB, which requires
following the rules 100%, if they need the above
features.
2. If it isn't introduced now, there will be a long
wait (probably 18 months or more) before it can
become mandatory, and before it's mandatory nobody
can depend on it, and thus can't use it.  And if
nobody is using it, there's no incentive to deploy
it, leading to a continuation of point (2) in the
arguments-against section above.

After much discussion back and forth, there was
consensus on moving lsbinstall out of lsb-core.
Since only lsb-core is part of the ISO submission
at this time (other LSB modules will be proposed later
as they are deemed more mature), this approach would
mitigate point (3) of the arguments-against, but
leaves (1) and (2) still open.  The two possible
approaches there remain to leave it in (in which case
a new module is needed to hold it - immediately after
the meeting it was proposed to move the entire
packaging section to a separate book, and while
no final decision was made, this would be a natural
home for lsbinstall);  or remove it as a required element.


A review of the other open bugs indicated there's one
other large category, which is the ELF/DWARF bugs.
These are primarily reports from lsbappchk which
encounters sections it does not know what to do with.
These seem to be required sections, yet finding
a specification for their contents so that appchk
knows how to check them has proven difficult 
(sometimes the only "spec" we've found is a pointer
to a mailing list message announcing the feature,
and a ChangeLog entry stating it has been added).
There was discussion whether these could be
implemented post-3.0 under the rule that LSB can
document "new" features in a minor release if they
are already industry-standard and everybody has
them with no known incompatibilities - effectively
it's a feature we "forgot".  There was not a
consensus on this approach, we'll need to reach one -
fix or defer.

In addition, there are some new symbols in libgcc_s
and some problems in the spec (bugs 899 and 951),
these do need to be fixed for 3.0.

Several other bugs including the brand-new 970 have
changes ready but not checked in, or believed fixed
but need another read-through to make sure they're
right.

There's been an issue all along with reliable
architecture references; at the moment there's a bug
open (820) that the links used for the PPC specs have gone
stale, as well as not really being a document at the
right level - describes and abi but not a processor
instruction set.  We have a new link, to a single unified
document, and will point to that. Some review will be
required to make sure it's still correctly referenced.
We continue to seek permission to mirror it to avoid
future stale link problems, but that part of the 
problem is not a blocker.


====

Subsequent to the meeting there was very lively
discussion on the LSB irc channel over lsbinstall,
which evolved the design considerably, but also
raised more questions.  In light of that and
other considerations, the LSB Steering Committee
voted June 2nd to leave lsbinstall out of the
required elements of LSB 3.  Adjustments are now
being made to reflect this change.

The current blocker buglist looks like this:

# [-]  769 -ELF/DWARF update rollup bug, depending on:
    * 93  -lsbappchk reports problem with gcc_except_table section.
    * 776 -.got.plt section not in LSB.
    * 777 -.data.rel.ro section not in LSB.
    * 846 -DWARF Comments #2.
    * 857 -EH data is still undefined..
    * 890 -'personality routine' is not defined.
    * 891 -Sizes not specified for all CIE & FDE members..
# 772 -dladdr() behavior is ambiguous.
# 784 -Generalize installation namespace rules.
# 818 -System Initialization chapter: multiple problems.
# 820 -The PPC Arch specs don't specify a Processor document.
# 821 -sysinit chapter: facility names unclear.
# 830 -package rules require manual intervention.
# 832 -sysinit: changes in initfuctions section.
# 853 -Inconsistency on symbol versions for duplicated symbols.
# 895 -Installation & Removal of init scripts is too complicated.
# 898 -Do we correctly specify x86_64.
# 899 -Missing symbols from libgcc_s.
# 951 -libgcc_s incorrect "header" information.
# 970 -getconf _CS_PATH doesn't work on most systems.