(→Package Management: s/yum/RPM/) |
(→Core Components: Change subsection to MeeGo Core Components) |
||
| Line 137: | Line 137: | ||
* 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. | * 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. | ||
| - | == Core Components == | + | == MeeGo 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: | 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: | ||
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. 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 for Platform Compliance:
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 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.
Platform API – the complete set of programming interfaces defined for MeeGo Core.
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.
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 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.
A compliant system may provide additional components, if they satisfy to the following requirements:
This section describes requirements aimed to ensure compatibility between executable files of third party applications and MeeGo compliant systems.
Implementations must support MeeGo API. The MeeGo API consists of the following:
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.
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 by the MeeGo Reference Implementation.
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 RPM repositories using PackageKit.
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.
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 MeeGo Core 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 MUST NOT depend on features outside this specification as this would affect the ability of the application to install.
Dependencies to MeeGo Core are allowed either in terms of package names or in terms of features, that are specified in Appendix A 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.
The MeeGo API is strongly preferred for applications.
Applications which link exclusively with libraries provided by MeeGo API 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.
Applications using the larger Platform API are not guaranteed compatibility. This is because there is no explicit guarantee that interfaces outside the MeeGo API will remain consistent, nor they work across all profiles.
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 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)