MeeGo 1.1 Compliance Specification
Draft Version 1.0.99.5 (Wiki page based on the .pdf version)
This document is a preliminary draft and all content is subject to change. No product compliance decisions should be based on this draft.
Copyright © 2010 The Linux Foundation
Linux is a registered trademark of Linus Torvalds. MeeGo is a registered trademark of The Linux Foundation.
Contents |
This specification defines the operating system interface and environment of the MeeGo operating system, to enable binary application compatibility. It is intended to be used by both application developers and system implementers, and to describe, for each audience, the requirements for MeeGo Compliance. A system implementation can be either a device running a MeeGo compliant software stack or a stand‐alone MeeGo compliant software stack.
MeeGo is a registered trademark of the Linux Foundation, which controls the usage of the brand and trademark. One of the requirements for permission to use this trademark is compliance with the requirements in this specification.
This specification sets forth two separate component categories:
These categories are additive: a profile layers on top of core to produce a complete description.
System implementations may only claim compliance to a specific profile. It is possible for a profile to be empty, in other words, to state that the requirements for the profile are satisfied by MeeGo Core.
Applications may comply either with a specific profile or, more generally, to MeeGo Core, to target multiple profiles.
The specification also defines two levels of application compliance:
For more details, see Definitions, on page 4, and the Application Compatibility chapter, on page 10.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" used in this document are to be interpreted as described in [ #RFC2119 ].
MeeGo API – the preferred set of programming interfaces defined for MeeGo Core. The compatibility promise for these interfaces extends to an entire major version of MeeGo.
Platform API – the complete set of programming interfaces defined for MeeGo Core. The compatibility promise for those interfaces that are not part of the MeeGo API is limited to the current version (major.minor) of MeeGo.
Repackaging – MeeGo Core packages may not be repackaged. This means the %files sections of the RPM spec file describing the package or subpackages may not be changed, only appended to. MeeGo Reference Implementation – the reference implementation shall be the source code released by the MeeGo project for the packages listed in Appendix A.
Instruction set – includes both the set of used instructions in binaries, which may require the use of optional features in the CPU architecture, and also different compiler options to generate optimal instruction scheduling for a specific implementation of the CPU architecture.
A compliant implementation is CPU architecture specific, and must provide a complete implementation, as required by the device category profile for that architecture. The implementation may provide additional components, as long as it does not replace or repackage the components required by the profile (see Definitions, on page 4).
It is permissible for a system implementation to provide alternative implementations of system components, provided that the components required by the profile are present and fully functional. For example, an alternative media framework can be provided, as long as the MeeGo media framework is also present and fully functional (so that applications depending on the MeeGo media framework continue to work correctly).
CPU architectures are approved by the MeeGo Technical Steering Group and may change over time. As of this version of the specification, supported architectures are:
Profiles are approved by the MeeGo Technical Steering Group and may change over time. As of this version of the specification, supported profiles are:
The fundamental purpose of this specification is to enable binary application compatibility on a particular architecture, while maintaining source compatibility across the entire MeeGo family. To that end, the following principles are in effect:
A conforming application shall satisfy the following requirements:
Compliant applications using only the MeeGo API set are assured compatibility with all future versions of MeeGo with the same major version number.
Compliant applications which use the larger Platform API are assured compatibility only with the specific MeeGo version they were built for.
There are no assurances that an application constructed for a particular version will run on any earlier version.
Components of the MeeGo Core software stack, as well as additional software for profiles, are specified in terms of source code in the package form released by the MeeGo project. These packages are described by a name and version, and the set will correspond to a particular MeeGo version. For the purposes of this specification, this will be known as the MeeGo Reference Implementation.
System implementers MUST use the source code of the MeeGo 1.1 Reference Implementation and SHALL NOT replace or omit core or profile components. They SHALL NOT repackage the software such that individual files appear in different binary package names than those used in the Reference Implementation. Modifications to the Reference Implementation are subject to the following requirements:
that such patches be submitted back to the MeeGo project.
A compliant system may provide additional packages, if they satisfy to the following requirements:
A compliant system shall supply the RPM Package Manager (RPM), as provided by the MeeGo 1.1 reference implementation, and support installation of all compliant RPM packages, as created by the corresponding version 4.8 rpm build tool. In particular, it shall support packages with the following payload compressions:
The system shall support installation and updating of packages from yum repositories using PackageKit.
A compliant system shall provide all MeeGo Core packages listed in Appendix A and marked as applicable for the given architecture. All packages shall be included in the default install. To ensure smooth installation of third party applications across all MeeGo compliant distributions, all the packages:
Note: The RPM package manager uses both techniques (feature‐based and file‐based) to resolve dependencies of packages to be installed, so it is important to keep these properties of core packages consistent across all MeeGo compliant distributions.
This section describes requirements aimed to ensure compatibility between executable files of third party applications and MeeGo compliant systems.
MeeGo systems shall support execution of object files in Executable and Linking Format (ELF), as specified in [ #ELF ], LSB [ #LSB40 ], and corresponding architecture‐specific supplements.
The default system dynamic linker (/lib/ld-linux.so.2 for Atom and /lib/ld-linux.so.3 for ARM), when run in the default environment, shall load all shared libraries required for compliance from the paths provided by the MeeGo 1.1 Reference Implementation. That is, except in debug and other special cases, required libraries must not be overridden by alternative versions.
A compliant system shall provide all MeeGo Core shared libraries provided by the binary packages referenced in Appendix A, and each such library shall export all the public symbols assigned to the library, keeping run‐time semantics of those symbols the same as in the MeeGo 1.1 Reference Implementation.
Implementations must support OpenGL ES 2.0 [ #OGLES ].
If the capabilities above are provided by an X Window System server, the following extensions are required:
SHM, RANDR, RENDER, SYNC, XFIXES, XInputExtension, XKEYBOARD, XVideo
If the driver stack is based on Mesa, additionally required are:
A compliant system shall use Linux kernel version 2.6.35 or later. Note: A minimum set of kernel configuration options may be required in a future version.
All MeeGo compliant applications SHALL be packaged in RPM package file format, with the exception of Web RunTime packages, which MAY use the native WGT format.
An application package name shall begin with one of the owners' fully qualified domain names in lower case, in reverse order, and end with the application name (such as, com.ovi.appname).
Application packages SHALL “require” (in RPM terminology) all system components that are necessary for them to run. They MAY omit optional dependencies, if such omission does not affect ability of the application to operate in a user friendly way, that is, omitting a dependency should not have the effect of allowing the application to install successfully, but then not operate correctly.
Application packages MAY NOT depend on features outside this specification as this would affect the ability of the application to install.
Dependencies on system components are allowed either in terms of package names or in terms of features, that are specified in Appendix A (for MeeGo Core components) and in the relevant profile chapter.
Application packages shall be created so that the package management system knows which files are installed. Queries on the installed packages, using standard package management tools, shall work as expected. Examples:
$ rpm –q –-file filename
$ rpm –ql packagename
Packages that install all files in a post install script are not compliant.
The application shall uninstall cleanly, leaving the system in the state it was in prior to installation (excepting any user‐added files or configurations).
An application shall be installed to /opt/packagename/ and, if necessary to the /etc/opt/packagename/ and /var/opt/packagename/ directories. System wide configuration files shall be placed in the /etc/opt/packagename directory rather than directly in /etc , unless a specific location is necessary for the application or system to operate correctly. Variable data from a package, such as lock files, cached files, etc. shall be placed in the /var/opt/packagename directory rather than directly in /var , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the ~/.config/packagename directory. The rationale for these rules is to avoid filename clashes between application packages and with system files, by defining portions of the filesystem certain to be unique to that application.
A .desktop file shall be installed under /usr/share/applications, and contain values for at least the following fields: Name, Comment, [Exec or Link], Icon, Type, and Categories.
The picture file specified in the Icon field of the .desktop file must be either SVG or PNG format. In the case of PNG format, the following sizes shall be provided: 16x16, 32x32, 64x64, and 128x128.
This section describes requirements aimed to ensure compatibility between executable files of third party applications and MeeGo compliant systems.
All MeeGo compliant binary executable files and shared libraries shall be in the ELF format, as described in section #Executable and Linking Format. They shall import external interfaces only from the following sources:
Additionally, the executable may use public interfaces from shared libraries specific to a MeeGo profile, but, in this case, the application will be compliant only with that profile. If the executable is a plug‐in for a MeeGo system component, it may import interfaces from an executable of the system component, and from shared libraries loading as part of that executable.
An application binary or shared library MAY use CPU architecture extensions and implementation specific features when building the binaries. If such usage would limit the portability of the application, the application must clearly identify the restrictions imposed as a result – application repositories/stores must be able to filter out devices which are not applicable. The mechanism for this is unspecified.
The default shell interpreter /bin/sh of any compliant system shall be bash version 4.0.
The default installation of any compliant system shall provide all of the commands and utilities specified in the package list of the MeeGo Reference Implementation.
The MeeGo API consists of the following:
Applications which link exclusively with these libraries are compliant for the major version of MeeGo they were built for. They are not necessarily compliant to earlier minor versions than the one they were built for. Applications should target the lowest applicable {major.minor} version of MeeGo for the widest portability.
The Platform API consists of public interfaces from all libraries provided by MeeGo Core (see Appendix A).
Applications using the larger Platform API are only guaranteed compatibility with the version of MeeGo for which they were built. That is, there is no explicit guarantee that interfaces outside the MeeGo API will remain consistent, or indeed will remain available, across releases.
The MeeGo API is strongly preferred for applications. The Platform API may be used when needed, but, in general, is recommended only when the MeeGo API is insufficient. Currently, some useful multimedia features are not supported by Qt or Qt Mobility. In addition, OpenGL‐based applications that are not using Qt will link directly with these libraries.
MeeGo 1.1 includes support for executing Web Runtime 1.2 [ #WGT ] applications. These are applications developed using standard web technologies, such as HTML, Javascript, and CSS. They are similar to web widgets or applets, except that they are run as full‐screen, stand‐alone applications on top of a Webkit based runtime engine.
Web RunTime is currently a technology preview and should be considered similar to the Platform API in that the compatibility guarantees are limited to the current MeeGo version.
Web Runtime applications are bundled as wgt packages (see [ #WGT ]). These are installed on the target system using a tool called widgetinstaller, which is part of the qt-web-runtime package and available on all MeeGo‐compliant distributions. Web Runtime applications (wgt files) MAY be packaged as RPMs for distribution purposes: application stores are likely to require this packaging format, and such files can be included in standard yum/zipper repositories. The RPM provides a simple wrapper that calls the widgetinstaller program with the wgt file. Note that this is an exception to the rule in section #Integration with RPM, which states that applications may not use a postinstall script to install files.
The following hardware capabilities are recommended but not required:
There are no additional package management requirements beyond those specified for MeeGo Core compliance.
There are no additional ABI and API requirements beyond those specified for MeeGo Core compliance.
A compliant Netbook implementation must provide the following functionality
libnotify or compliant with the Desktop Notifications Specification 0.9 defined in [ #Notify ]
There are no additional packages required beyond those specified for MeeGo Core compliance.
(not copied)