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

Ian Murdock imurdock at imurdock.com
Tue Aug 1 07:38:56 PDT 2006

Attendees: Rajesh Banginwar, Stew Benedict, Todd Fujinaka, Jon maddog
Hall, Marvin Heffler, Russ Herrold, Till Kamppeter, Jeff Licquia, Ian
Murdock, Robert Schweikert, Aaron Seigo, Mats Wichmann

The entire call was devoted to the LSB roadmap, currently in the process
of being written. Rough outline and discussion topics:

* Core. Not terribly different from LSB 3.0 and 3.1. Some interfaces are
being added based on ISV feedback, most notably from IBM Chiphopper,
which is an LSB superset.

* C++. Not much we can do directly in terms of masking the problem
through a shim layer of some sort. Best option is to get involved and
see what we can do to help fix the problem upstream. It was suggested
that we arrange a meeting with key GCC/libstdc++ developers and distros
to discuss ABI compatibility issues. Ian will talk with Aaron Seigo
to get up to speed on the issues and get introduced to the key players.

* Perl. Will be added to 3.2. Looking for someone from the Perl
community to take the lead here and advise us on next steps.

* Python. Will be added to 3.2. Looking for someone from the Python
community to take the lead here and advise us on next steps.

* Java. Depends entirely on when Java gets open-sourced.

* Desktop. Four freedesktop.org specifications (Desktop entry, Icon
theme, Menu, and Desktop base directory) are in the process of being
added to 3.2 (all are already best practice). The real question mark is
xdg-utils (aka Portland), which provides a unified command line
interface to these standards--their inclusion in 3.2 depends entirely on
whether the distros include them in a service pack release of their
current generation (RHEL 5, SLES 10, etc.). In any event, we will move
forward to put together an "optional module" for Portland, much as we
did for Qt 4 in LSB 3.1. We should also revisit Qt 4. Whether this is a
3.2 candidate depends entirely on whether Red Hat ships it in RHEL 5.

* Packaging. The problem is that ISVs want to use their own installation
methods (e.g., an installation script or a cross-platform installation
framework like InstallAnywhere) rather than using the distros' native
package systems. The reasons are varied, but typically have to do with
controlling the user experience and providing better cross-platform
support, since Linux is almost always just one platform that's supported
among others. Current methods simply dump files in the file system and
integrate poorly with the underlying package systems. The solution
proposed at the LSB face to face in June is to construct an API to the
package systems (dpkg, RPM, APT?, yum?) so that higher level installer
frameworks can register with them. That way, third parties
can completely control the installation experience, yet the end result
is properly integrated with the distros' software management
tools. More discussion is needed here, making it squarely a 4.0 issue.

* Printing. Printing support in 3.2 is focused on two broad areas:
Driver support and application interfaces. On the driver side, we are
looking to add OpenPrinting Vector and IJS, both of which are best
practice (by virtue of Ghostscript integration). Also, the OpenPrinting
workgroup is putting together an extension to the FSG defining standard
locations in the file systems for printer drivers and filters. Whether
this is a 3.2 candidate depends on whether or not the distros include it
in a service package release of their current generation products (RHEL
5, SLES 10, etc.). This is believed to be realistic because it will be
possible to implement the standard in a non disruptive fashion using a
symlink tree. On the application side, CUPS is being deferred to 4.0 for
now. Since this is largely being driven the needs of desktop group, in
3.2, printing APIs will be provided by the desktop toolkit.s (For 3.2,
this effectively means just KDE/Qt, as Gtk 2.10, which added the
printing APIs, will not be a candidate till LSB
4.0, as it is not included in one or more of the major distros.)

* Multimedia. LSB 3.2 will focus on device level standards (e.g.,
ALSA, libao). LSB 4.0 will focus on the higher level multimedia
frameworks (e.g., GStreamer, Helix). The FSG is forming a
Multimedia workgroup to lead this work. More details to come...

* I18n. We are currently exploring the possibility of merging OpenI18n
with the LSB beginning with LSB 3.2. More details to come here as well.

* Accessibility. FSG Accessibility standards being integrated with LSB
3.2. Work led by the FSG Accessibility workgroup.

* Font management. Can we define a common set of fonts required
to be available on LSB compliant desktops, so that a document
created on one LSB compliant system looks the same on another LSB
compliant system? Beyond this, the distros are interested in getting
out of the font business. This is a larger issue than the LSB--we
want a document created e.g. on Windows to look the same
on Linux too. Looking into working with OASIS, freedesktop.org,
and other organizations to help address this action item.

Ian Murdock

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

More information about the lsb-discuss mailing list