[lsb-discuss] LSB conference call minutes (Tuesday, August 1, 11am ET)

[Ian Murdock]

Attendees: Rajesh Banginwar, Darren Davis, Todd Fujinaka, Marvin
Heffler, Andrew Josey, Till Kamppeter, Jeff Licquia, Ian Murdock,
Robert Schweikert, Mats Wichmann

* Discussion of network interfaces on lsb-discuss and the larger
discussion of interfaces that have been deprecated but are still
broadly used. Consensus here is because the LSB is a pragmatic
standard, an interface should not be removed while it is broadly
used. If POSIX etc. marks an interface as deprecated, we should
follow suit (so the tools issue warnings etc.), but we should not
remove it until the ISVs have transitioned. And, as previously
discussed, there will be a minimum number of major releases an
interface must be marked deprecated before it can be removed.
(The number is still being discussed, but consensus is that
it needs to be greater than the current value, which is one.)

A word on the motivation: Many ISVs utilize third party components
for which they do not have source. Therefore, if an
interface is used by one of these components but is not in the LSB,
the ISV cannot do anything about it, and thus cannot achieve LSB
compliance no matter how much they otherwise might want to do that.

Action item: We should strongly consider adding the deprecated
interfaces that have been removed back into LSB 3.2. For ISVs
wishing to achieve LSB 3.0 or LSB 3.1 compliance, we should
strongly consider granting waivers. This is arguably a bug in the
LSB, as widely used interfaces should not have been removed.

* Discussion of dlopen and LSB compliance. If an application
uses dlopen to utilize functionality not specified by the LSB
(e.g., CUPS), can that app still be considered compliant?
Consensus is yes, provided the application deals gracefully
with that functionality not being present.
This case will be tested when the app is run on the LSB SI.

* Discussion of the ISP RAS proposal. Concerns about complexity
and ability to leverage existing tests and skill sets. The ISP
RAS group will be joining the call on Aug. 8 to discuss further.

* Beginning discussion of the LSB SDK. The SDK (lsbcc etc.) should
be separate from the testing tools. We should provide a VMware
image of the SI to make it easier for app vendors to test against
it (won't be available on all platforms but the most common ones).
We should take a deep look at the ability of the SDK to generate
packages that target multiple LSB versions, perhaps even non-LSB
compliant systems as well. Among other things, this would help us deal
with the "RHEL 3 problem", which is that all the major distros an ISV
might want to target are at least LSB 3.0 compliant except for RHEL 3.

Robert is on vacation next week. We will continue the SDK discussion
Aug. 15.

-ian
-- 
Ian Murdock
317-863-2590
http://ianmurdock.com/

"Don't look back--something might be gaining on you." --Satchel Paige