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.
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.
See the ProjectPlan50 page for the current schedule and status.