Revision as of 12:09, 23 December 2010

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.

Introduction

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.

Scope

This specification sets forth two separate component categories:

• MeeGo Core: a core set of operating system components (or ''stack''), as provided by the MeeGo project, is always required, and may not be replaced or repackaged (see Definitions).

• MeeGo Profile: a targeted description for a device category, including additional components, device category programming interfaces, minimum hardware requirements, and more. Profile software components are subject to the same no‐replace rules as core components.

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:

• MeeGo API
• Platform API

For more details, see Definitions, on page 4, and the Application Compatibility chapter, on page 10.

References

• Native Platform Graphics Interface http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf

• Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification Version 1.2 http://refspecs.linuxfoundation.org/elf/elf.pdf

• GStreamer 0.10 http://apidocs.meego.com/platform/gstreamer‐0.10/

• ISO/IEC 23360:2005 Linux Standard 32 Base ‐ Part 1 Generic Specification http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html

• MeeGo Touch Framework http://apidocs.meego.com/mtf/

• Desktop Notifications Specification 0.9 http://www.galago‐project.org/specs/notification/0.9

• OpenGL ES 2.X http://www.khronos.org/opengles/2_X

• PulseAudio 0.9.21 http://apidocs.meego.com/platform/pulseaudio‐0.9.21/

• Qt Reference Documentation, version 4.7 http://apidocs.meego.com/qt4.7/

• Qt Mobility Project APIS http://apidocs.meego.com/qtmobility/

• IETF RFC 2119 Key words for use in RFCs to Indicate Requirement Levels http://www.ietf.org/rfc/rfc2119.txt

Definitions

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.

Requirements

System Implementation Compliance

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:

• Intel ® Atom ™ (Core2/Atom instruction set (SSSE3))
• ARM v7 (ARM EABI, VFPv3 support, softfp float ABI)

Profiles are approved by the MeeGo Technical Steering Group and may change over time. As of this version of the specification, supported profiles are:

• Netbook

Compliance Principles

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:

• Where this specification is silent, ambiguous, or incomplete, regarding a particular behavior, it is the responsibility of the system implementer to ensure compatibility with the Reference Implementation. That is, notwithstanding any specific wording in this specification, the behavior is defined by the reference source code.

• If a compliant binary application operates correctly on the Reference Implementation and fails on another implementation, it is the responsibility of the failing implementation to resolve the conflict.

Application Compliance

A conforming application shall satisfy the following requirements:

• The application may be CPU architecture specific, and, if so, must follow all the requirements for that architecture.

• The application’s executable files shall be either object files in the format defined for that CPU architecture, and/or scripts or intermediate code, written for one of the programming language interpreters described in this specification.

• The application shall be assembled into a package of the supported form required by this specification.

• The package shall identify the version of this specification the application conforms to, and shall identify the profile it requires, if any.

• Any executable and non‐executable files, belonging to the application, shall be placed only in locations in the file system hierarchy allowed by this specification.

• The application shall use only external commands and other facilities described in this specification, whether for installation tasks or run‐time tasks.

Forward and Backward Compatibility

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.

Platform Compatibility

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.

Platform Source Code Modification Policy

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:

• Patches MAY be applied against source packages if necessary (for example, to fix bugs found in the field), but changes MUST NOT affect API, ABI, or behavior.

• All patches SHALL be provided as patch files within corresponding SRPMs. It is recommended

that such patches be submitted back to the MeeGo project.

• Patched packages SHALL have an updated minor version or suffix to distinguish them from the package released by the MeeGo Reference Implementation. The exact form of disambiguation is unspecified.

• A MeeGo compliant distribution MUST use the same tool chain and the same compiler options as the reference implementation. A package MAY be compiled to use a specific instruction set, to optimize for the target device.

Additional System Packages

A compliant system may provide additional packages, if they satisfy to the following requirements:

• MUST NOT overwrite MeeGo packages

• MUST NOT conflict with file system namespace of MeeGo ABI, utilities, and interpreted languages

Package Management

System Package Manager

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:

• gzip
• bzip2
• xz
• lzma

The system shall support installation and updating of packages from yum repositories using PackageKit.

Core Components

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:

• SHALL ''provide'' (in RPM terminology) all features assigned to the corresponding package in appendix A

• SHALL contain all files assigned to the corresponding package in Appendix A

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.

ABI and API

This section describes requirements aimed to ensure compatibility between executable files of third party applications and MeeGo compliant systems.

Executable and Linking Format

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.

Dynamic Linker

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.

Core Shared Libraries

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.

Graphical Subsystem

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:

• BIG‐REQUESTS, Composite, DAMAGE, DPMS, Generic 181 Event Extension, MIT‐SCREEN‐SAVER, MIT182

SHM, RANDR, RENDER, SYNC, XFIXES, XInputExtension, XKEYBOARD, XVideo

If the driver stack is based on Mesa, additionally required are:

• DRI2, GLX

Kernel

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.

Application Compatibility

Packaging Compliant Application Packages

All MeeGo compliant applications SHALL be packaged in RPM package file format.

Package Naming

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

Dependencies

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.

Integration with RPM

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:

• Find the package that a file belongs to:

$ rpm –q –-file filename

• List all files installed by a package:

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

Layout in Filesystem

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.

Desktop Integration

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.

API and ABI

This section describes requirements aimed to ensure compatibility between executable files of third party applications and MeeGo compliant systems.

Compliant Application Executables

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:

• shared libraries supplied as a part of the application package

• MeeGo Core shared libraries, if the interface is a part of the public interfaces of that library

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.

Use of Implementation-Dependent Instruction Sets

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.

Command and Utilities

Default Shell Interpreter

The default shell interpreter /bin/sh of any compliant system shall be bash version 4.0.

Commands and Utilities

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.

MeeGo API Applications

The MeeGo API consists of the following:

• Qt 4.7 [ #Qt47 ]
• Qt Mobility 1.0 [ #QtMob ]

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.

Platform API Applications

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 Netbook Profile Specification

Hardware Requirements

The following hardware capabilities are recommended but not required:

• Network connectivity provided by one or more of the following: WiFi / Ethernet / 3G data / WiMAX

• A physical keyboard and pointing device

• A minimum screen resolution of 1024x600 pixels

• A minimum of 1024 MB of RAM

Package Management

There are no additional package management requirements beyond those specified for MeeGo Core compliance.

ABI and API

There are no additional ABI and API requirements beyond those specified for MeeGo Core compliance.

Other Requirements

A compliant Netbook implementation must provide the following functionality

• a window manager that supports running MeeGo compliant applications

• a notification system using libnotify or compliant with the Desktop Notifications Specification 0.9 defined in [ #Notify ]

• the ability to launch MeeGo‐compliant applications

• a network configuration UI supporting ConnMan

Netbook Profile Packages

There are no additional packages required beyond those specified for MeeGo Core compliance.

Appendix A – MeeGo Core Packages

(not copied)