From The Linux Foundation
Jump to: navigation, search

At the LSB F2F Spring 2011, a number of proposals were discussed that related to modularization: the idea of splitting the LSB into multiple pieces, each of which could be targeted by ISVs and/or distributions. These proposals boiled down to two major ideas: exposing our current modules to end users, and a more radical proposal called "Runtime Profiles".

One or both of these proposals will likely become part of LSB 5.0.

After discussion, we've determined that the Runtime Profiles proposal isn't really about modularization itself, and also doesn't have the same impact on the spec. So, it has been given its own page, and isn't tied to any spec release.


LSB, as it is organized today is one monolithic blob from the perspective of the distribution vendor and from the perspective of the ISV/application provider. This leads to potential issues at the end customer, for example if a customer wants to install an application that is LSB compliant or certified, but does not use any graphics components (openGL, Qt, Gtk+, X11 etc.), however it requires the LSB package, the customer must install the LSB as a whole, i.e. openGL, Qt, Gtk+, X11 etc. come along for the ride. While disk space is generally not a concern, the additional footprint of installed software is in various cases a security concern.

The problem also manifests itself from the application provider perspective. Generally it is the goal of the ISV to depend only on as small a set of possible of external software. This allows the ISVs customer to install a minimum set of additional software along with the ISVs application and therefore reduces potential installation and other problems. However, if an ISV wants to advertise/market the application as LSB compliant, the ISV has no choice but to "depend" on all of the LSB, although most of the dependencies will be artificial, from a code perspective.

From a distribution vendor perspective dealing with this problem takes on a different form. First and foremost the distribution vendor has to address customer complaints about the situation outlined above. Secondly, because of the scope of the LSB it is difficult to maintain all the detailed dependencies in a single place due to the size. This may lead to bugs in the distribution.

As the LSB evolves and includes more interfaces and libraries the problem of being a monolithic blob will only be exacerbated.

Proposal: Expose Modules

While externally the LSB is one big monolithic blog, from an internal view the LSB already has a general structure that supports granularity. The so called 'modules' in the LSB could relatively easily be exposed as "components" and "sub-components". Exposing components would allow distribution vendors to create packages along the concept shown in the figure below:


The individual packages have a 1 to 1 relationship to the LSB components and sub-components. In order to certify to the LSB a distribution vendor must provide all components (partial certification is not allowed). Certification tests must be passed etc.

The LSB application checker needs to gain knowledge of the LSB components and provides a list of the components an application depends on at the end of the application check. The application provider can then use this information to specify the appropriate dependencies. This meats the goal of the ISV to keep dependencies small. As long as the application does not need any interfaces outside the LSB the application can claim LSB compliance and can certify to the LSB if desired.

From an end customers perspective the "pulling in too much" problem is now resolved, as the LSB compliant application only depends on the components of the LSB it actually requires and only those components will need to be installed.

For the distribution vendor the increased granularity increases the number of packages that need to be maintained. However, the maintenance as a whole becomes easier as each package is much less complex than the current monolithic lsb package maintained by distribution vendors.

The lsb-release tool must be enhanced to provide information about the components and sub-components that are installed on a system and to provide information about what components and sub-components are available in the LSB.


  • What are the components, sub-components?
    • The LSB contains reasonable module specifications that can be used as an initial starting point for components and sub-components. Guidelines for exposure and grouping could be
      • Size of any given component, if a component gets too big it might make sense to break it into sub-components.
      • Logical association of function along reasonable guidelines, for example few people will probably associate sound with a server in a data center.
    • As long as components maintain a reasonable size, and considering the rather lengthy release cycles of the LSB and enterprise class distributions having some movement of libraries/interfaces between components is not considered to be an issue.
      • Churn is low
      • Movement is easy
    • An initial proposal can be drawn up an vetted on the lsb-discuss list
  • How are the dependencies handled?
    • Distributions have different package naming conventions that might pose a problem.
      • The LSB will prescribe the beginning of the package names, such as lsb-core, postfix after the prescribed name can be distribution dependent
      • The LSB will describe sub-component names and component dependencies on sub-components.
      • The LSB will describe the libraries/interfaces to be provided by a given component or sub-component isolating the LSB package from distribution dependent package naming.
  • What is the meaning of lsb-release in the new frame work and how is information provided?
    • lsb-release still provides version information about the LSB version the given distribution is certified.
      • All components for the LSB on this distribution are components from the advertised version of tehe LSB
    • lsb-release will present information about he LSB components installed on the system
      • The name presented is prescribed by the prefix that is also described for the package names, see note above.
    • lsb-release will be able to present information about the components available.


See the ProjectPlan50 page for the current schedule and status.