Revision as of 12:15, 9 May 2011

Compliance Implementation

Definition

The objective of Compliance is to provide a base set of functionality that application writers can depend on being there - effectively, an ABI plus other supporting details.

There are two aspects to compliance:

• For application writers, the key aspect is the set of services (libraries, services such as dbus, etc.) that are always present, so that apps know they can use them safely. It also includes a picture of which of those will be consistently provided in future releases so developers can detemine whether their apps will be "future-proof" or not.
• For device implementors, what is needed is a complete picture of what must be delivered, not just the external ABI view, so dependencies are also part of the picture.

In effect, the MeeGo Architecture makes up the starting point for compliance, while the the dependencies of the architecture packages can be seen as providing functionality "on behalf of" the architecture packages so to be practical, they end up in compliance as well. Dependencies could change over time - a dependency in 1.2 might not be a dependency in 1.3 any longer, so this part should not be counted on by applications; but for a given MeeGo release, dependencies are mandatory for devices.

MeeGo Core vs. Compliance

The Compliance set does not need to describe a bootable system, indeed does not need to be a "real OS", it's just the minimum set an OSV needs to provide so that ISVs get a "compatible" OS.

Meego-core on the other hand actually needs to boot, so there's a bunch of things in there that are needed to boot, but that an application couldn't care less about. Bootloaders are a quick example of things that must be in core, but are not important for compliance.

So for all intents and purposes, compliance ends up being a subset of core.

As an example, compliance could include a requirement to handle sysv initscripts, but not describe how that requirement is to be met, so an OSV could replace the exsiting init processing with upstart. As long as the sysv initscripts are handled correctly, that's compliant.

Implementation of Compliance

Since package groups are used to drive image creation anyway, proper grouping can make keeping track of compliance straightforward.

Conceptually, these patterns could be used:

• Base: bootable system, not compliant
• Compliance: Application Compliance packages
• Core = Base + Compliance
• Derived Compliance (need a better name for that) : Compliance and its dependencies
• Hardware Adaption Groups
• UX Groups

The MeeGo package-groups git tree (git://gitorious.org/meego-os-base/package-groups.git) now has these patterns to describe the compliance picture (additional patterns for adaptation, UX, etc):

• meego-base.xml - Basic system
• meego-compliance.xml - Packages needed for Compliance
• meego-full-compliance.xml - MeeGo full compliance including core compliance and its dependencies
• meego-core.xml - MeeGo Core OS

As a note, there is some compliance stuff that isn't expressed as a specific pattern, and has to be handled separately:

• Kernel 2.6.35 or later -We have separate kernel for separate platforms
• /usr/lib/libEGL.so.1 - we have separate gfx package to provide this
• /usr/lib/libGLES2.so.1 - we have separate gfx package to provide this