The Linux Foundation

 
LSB face-to-face (December 2006)

From The Linux Foundation

The date of the next LSB face-to-face and the first FSG Packaging Summit is now set: December 4-6, 2006. SAP will be providing facilities for the meeting at the SAP office in Berlin, Germany.

This will be a three day meeting. The first two days (Monday, December 4 and Tuesday, December 5) will be the LSB face-to-face meeting. The primary agenda will be to finalize the LSB 3.2 roadmap and timeline.

Wednesday, December 6 will be the first FSG Packaging Summit. The goal of the Summit is to bring together the key people in the Linux packaging world and ISVs to discuss the future of Linux packaging. Topics will include RPM, the role of other packaging technologies (dpkg, APT, yum, etc.), and the needs of ISVs in packaging solutions.

Agenda

LSB face-to-face, day one (December 4)

Day one will focus on current status and recent progress at the LSB; a high level discussion of goals and priorities; feedback from the Linux platform stakeholders; and project infrastructure and deliverables, including the new LSB database and testing framework, tools, documentation, and developer network.

DRAFT schedule: December 4
9:00am - 9:15am Welcome, introductions, and overview of day one (Ian Murdock)
9:15am - 10:00am LSB overview and progress report (Ian Murdock)

I will present the standard LSB slide deck with a particular focus on progress since the last face to face meeting, to ensure we're all starting the meeting on the same page. I will also present the current draft of the LSB 3.2 roadmap and timeline. Finally, I will talk about organizational issues, the modular structure of the LSB, etc. as they relate to LSB 3.2 development.

Presentation

10:00am - 10:45am Feedback: What do key platform stakeholders (distribution vendors, ISVs, OSVs, upstream developers) want from LSB 3.2 and beyond? How does/should the LSB add value?
10:45am - 11:00am Break
11:00am - 12:00pm Overview of the LSB infrastructure project (Vladimir Rubanov and Alexey Khoroshilov)
  • High level overview of the LSB infrastructure project - long term objectives
    • Renewed integrated LSB DB with extended information to involve various community parties.
    • New software infrastructure systems (LSB DB Navigator, LSB TEF, LSB Certification System).
    • Linkage between all the key artifacts.
    • Improved test coverage and quality of the standard as a whole.
  • Current progress:
    • LSB DB & Scripts clean-up
    • LSB DB Navigator demo
    • LSB Test Execution Framework
  • The next stage overview

Presentation

12:00pm - 1:00pm Lunch
1:00pm - 1:30pm LSB Distribution Testkit (Jiri Dluhos, Alexey Khoroshilov, Ian Murdock)

Overview of the plans for the LSB Distribution Testkit (companion to LSB Distribution certification), demos of lsb-autotest and the LSB Test Execution Framework (TEF), and discussion of planned integration with the FSG certification system.

Presentation

1:30pm - 2:00pm LSB Application Testkit (Jeff Licquia)

Overview of the plans for the LSB Application Testkit (companion to LSB Application certification), demo of the new appchk, and discussion of planned integration with the LSB database and Developer Network.

2:00pm - 2:30pm LSB SDK and packaging tools

The current LSB SDK makes it easy to create an LSB compliant binary, but doesn't yet make it easy enough to create a distributable, easy to install LSB compliant application (I'm avoiding the term "package" here, intentionally). Longer term plans will be discussed in Wednesday's Packaging Summit. In this session, we'll discuss shorter term plans for making it easier to create distributable LSB applications that integrate well, such as including RPM helpers, alien, APT/yum repo generators, etc. in the LSB SDK.

2:30pm - 3:00pm Break
3:00pm - 4:00pm Perl, Python, and other interpreted languages

An increasing number of "Linux" applications are being written in or augmented with Perl, Python, and other interpreted languages. As a result, we will be adding Perl and Python to LSB 3.2, so that application developers can write LSB compliant applications in those languages in addition to C and C++. However, the addition of interpreted languages presents the LSB with some new challenges, such as whether or not add-ons (e.g., gtk bindings) should be standardized and how to handle binary extensions. See also: LsbInterpretedLanguage, LsbPerl, LsbPython. Martin v. Löwis of Python will be joining us for this discussion and helping with Python standardization in LSB 3.2.

Incorporating Python into LSB: Identification of Issues (Martin v. Löwis)

4:00pm - 4:45pm LSB Developer Network

In October, the FSG launched the LSB Developer Network, a community resource for developers building portable Linux applications via the LSB. In this session, we will discuss current status and future plans for the Developer Network, including collaboration possibilities with other developer communities.

4:45pm - 5:00pm Day one wrapup


LSB face-to-face, day two (December 5)

Day two will center around finalizing the roadmap and timeline for LSB 3.2 (June 2007). Roughly speaking, to be considered for inclusion in LSB 3.2, the interface must be present in the current generation of distros (e.g., RHEL 5, SLES 10, etc.) (or be a small enough increment to existing interfaces that it can be included in a service pack/update/etc.). We will also discuss LSB futures (LSB 4.0 and beyond).

DRAFT schedule: December 5
9:00am - 9:15am Review of day one, overview of day two (Ian Murdock)
9:15am - 9:30am LSB 3.2 printing roadmap and timeline (Ian Murdock)

I will present the final LSB 3.2 printing roadmap and timeline prepared at the FSG Printing Summit in October. This presentation is both to inform attendees of our printing related activities for LSB 3.2 as well as to provide a guide of what I want to produce for the rest of LSB 3.2.

Presentation

9:30am - 10:30am Core and C++ (Mats Wichmann)

In general, not much is changing here. However, we need to look at the following issues:

  • We are conducting a review of symbols that were previously in the LSB (during 1.x and/or 2.x) and have been removed but are still in widespread use (i.e., are still best practice). Where practical, these symbols will be readded to the LSB in 3.2 and waivers will be granted so that LSB 3.0 and 3.1 applications that wish to use them may do so. The primary consideration here are third party libraries such as FLEXlm that many ISVs use but cannot change to make their applications compliant. See ISV Requested Interfaces.
  • In LSB 3.1, compliant applications depend on a single metapackage called 'lsb', so an LSB compliant runtime should provide that metapackage and provide all the required components when it gets installed. In LSB 3.2, we'll allow applications to only depend on the subset of the LSB they require (e.g., lsb-core). This will allow LSB applications that do not require the desktop components to be installed without pulling in the desktop components via the 'lsb' dependency.
  • Mats: Other things?
10:30am - 10:45am Break
10:45am - 12:00pm Finalizing LSB 3.1 Update 1 (Mats Wichmann)

We will be releasing the first update to LSB 3.1 in early 2007. The current working timeline is to release the beta on December 15 and the final version on January 15. In this session, we will finalize the timeline and go through the to-do list to determine what will make it into the update and what won't.

12:00pm - 1:00pm Lunch
1:00pm - 1:30pm Accessibility (Olaf Schmidt)

Presentation

1:30pm - 2:00pm Multimedia (Donya Shirzad)

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).

Presentation

2:00pm - 2:30pm OpenI18n

OpenI18n is being merged into the LSB beginning with LSB 3.2.

2:30pm - 2:45pm Break
2:45pm - 4:15pm LSB Futures (or: LSB 4.0 and beyond)
  • dbus
  • Java
  • OpenSSL
  • Packaging (see Packaging Summit)
  • Virtualization
  • What else should be on our radar?
4:15pm - 4:45pm Desktop

LSB 3.2 Desktop Updates (Tracy Camp (by phone))

4:45pm - 5:00pm Day two wrapup


Packaging Summit (December 6)

The main packaging systems under Linux include three main components: a format for bundling software to be delivered onto a system including mechanisms for indicating dependencies on other packages; a database for tracking installed software; and utility programs for creating, installing, and manipulating software packages. Many higher-level systems (e.g. apt, yum, RHN, urpmi, Red Carpet) exist which provide an easier to use user interface, but still depend on the package format and database. The LSB currently contains a specification for the package format only, leaving the other parts as implementation details.

For a variety of reasons, third-party developers may be unwilling or unable to use the native package systems, and may use some other mechanism such an installation script or a cross-platform installation framework like InstallAnywhere. 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. It is quite difficult for external packagers to effectively tie in to the automatic dependency generation which is an important part of the distribution-provided packaging, and doing so often makes the vendor package less portable than is desired. The LSB does attempt to simplify this by providing a single dependency ("lsb") for packages which covers all of what the LSB covers.

The methods used by third-party developers effectively just dump files in the file system and integrate poorly with the underlying package systems, which is a problem for system administration, IT support, compliance audits, and many other reasons. At the LSB face to face in June (and elsewhere) it has been proposed to construct an API to the native package systems (dpkg, rpm) 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.

DRAFT schedule: December 6
9:00am - 9:30am Overview, goals, and motivations (Ian Murdock)
9:30am - 10:45am ISV issues: What do ISVs want to see in a Linux software management solution?
  • ABAQUS (Robert Schweikert)
  • RealNetworks (Donya Shirzad)
  • SAP (Falko Flessner/Andreas Hahn)
10:45am - 11:00am Break
11:00am - 12:00pm Distribution issues: How do distros see the software management problem?
  • Debian (Joey Hess)
  • Red Hat (Paul Nasrat)
  • Novell (Thorsten Kukuk/Michael Schroeder) Presentation
  • Ubuntu (Michael Vogt)
12:00pm - 1:00pm Lunch
1:00pm - 1:30pm APT (Michael Vogt)
1:30pm - 2:00pm Yum plans post-API freeze (Seth Vidal)

Some of the loose plans we have for the 3.2.X cycle following on the API freeze for 3.0. What these plans mean for fedora and other distros using yum and what things we hope to do.

2:00pm - 2:30pm alien (Joey Hess)
2:30pm - 3:00pm Break
3:00pm - 3:30pm Packaging for people who aren't distros: autopackage and other problems (Mike Hearn (by phone))

Presentation

3:30pm - 4:00pm The philosophy behind klik: 1 application = 1 file (Simon Peter)

klik is an easy way to download and use software. The idea behind klik is that software should just run, without the need for installation. To achieve this, klik uses compressed image files, not unlike Mac DMG files, that contain the entire application and all its dependencies that are not part of the (LSB) base system. This allows for "portable applications" that can be run from all media, e.g., USB thumbdrives. Presentation

4:00pm - 4:45pm Open discussion: What can the LSB do to improve software installation and management on the Linux platform? (Ian Murdock)
4:45pm - 5:00pm Packaging Summit wrapup


Attendees

  1. Stew Benedict (Mandriva) (via phone)
  2. Hans Friedrich Blenkle (Xandros) (Tuesday and Wednesday only)
  3. Darren Davis (Novell)
  4. Joachim Deguara (AMD)
  5. Jiri Dluhos (Novell/SUSE)
  6. Falko Flessner (SAP)
  7. Andreas Hahn (SAP)
  8. Joey Hess (Debian/alien)
  9. Till Kamppeter (FSG)
  10. Alexey Khoroshilov (ISPRAS/linuxtesting.org)
  11. Dan Kohn (FSG)
  12. Matthias Klose (Canonical/Ubuntu) (Monday and Tuesday only)
  13. Thorsten Kukuk (Novell/SUSE)
  14. Pascal Lauria (Xandros) (Wednesday only)
  15. Michael Leibowitz (Intel) (Wednesday only)
  16. Jeff Licquia (FSG)
  17. Martin v. Löwis (Python)
  18. Ian Murdock (FSG)
  19. Paul Nasrat (Red Hat, Software Installation (Anaconda, RPM, yum))
  20. Simon Peter (klik)
  21. Vladimir Rubanov (ISPRAS/linuxtesting.org)
  22. Steve Schafer (FSG)
  23. Olaf Schmidt (KDE/FSG Accessibility workgroup) (Tuesday and Wednesday only)
  24. Michael Schroeder (Novell/SUSE) (Wednesday only)
  25. Robert Schweikert (ABAQUS)
  26. Donya Shirzad (RealNetworks)
  27. Seth Vidal (Fedora, yum lead developer and maintainer)
  28. Michael Vogt (Canonical/Ubuntu, APT/Synaptic maintainer)
  29. Mats Wichmann (Intel)

Travel

Regular flights to Berlin usually arrive at the Berlin-Tegel (TXL) or the Berlin-Schoenefeld (SXF) airport. Both are well connected to the inner city via shuttle trains and buses. The SAP building itself is located at Rosenthaler Str. 30, 10178 Berlin. Global coordinates are N: 52° 31.559', E: 13° 24.175'.

The next underground metro station is "U Weinmeisterstrasse", which is direct in front of the SAP building. The next urban rail system station is "S Hackescher Markt". More informations about public transport services are available at bvg.de (english version).

Accommodation

SAP has a Partnership with hotel.de. Choose the location "Berlin - Rosenthaler Str. 30" to find hotels nearby the SAP office.

Resources

Group photo in front of the Brandenburg Gate


[Article] [Discussion] [View source] [History]