MeeGo wiki - User contributions [en]

AgileBrowser

2011-06-28T10:53:36Z

Mythi: Add an example file /* Dependency file generation */

[[File:header.png]]

[http://wiki.meego.com/images/AgileBrowser.zip Download AgileBrowser installer]

= Introduction =

AgileBrowser is a free architecture management tool. It abstracts and visualizes software models of MeeGo OS. The main focus is to provide easier access to up-to-date architecture information gathered from multiple sources. The models contain stuctural and dependendency information. There are several types of external attributes to be attached to the information. Users of AgileBrowser can navigate, search, highlight with colors, share and export diagrams in various abstraction levels according to their individual needs.

[[File:overview.png|center]]

= Getting Started =

== Installation ==
Installer package is available in this wiki: [[File:AgileBrowser.zip]]

AgileBrowser can be run on Windows, Mac, Linux, etc., anywhere where Java is supported. The most important requirement is that the tool is memory expensive so it is recommended to have 1 GB RAM or fast swapping.

== Dependency file generation ==

To use AgileBrowser, a dependency metadata file is needed. For a quick start, download an example dependency file [[File:sf2011-deps.txt]].

The following gives instructions to generate the dependency metadata file from scratch.

# Checkout [[https://gitorious.org/meego-architecture/meego-deps-gen meego-deps-gen ]] project
# Get a package list (.packages) from any of the MeeGo images directory
#* Syntax <code><packagename>.<arch> <ver>-<rel></code>
# Get OSS and NON-OSS repodata primary XMLs for the same release
#* Download, unzip and rename as oss.xml and non-oss.xml
# Merge oss.xml and non-oss.xml into primary.xml
#* <code>sh merge-repodata.sh</code>
# Generate dependencies
#* <code>sh create-deps.sh <packagelistfilename>.packages</code>

= User Guide =

There are different guides available. Quick guide is for basic use cases of Agile Browser. In Quick Guide user is introduced to basic functionalities via simple example. Full User Guide contains all the functionalities of the tool.

== Quick Guide ==

It is time to take a closer look what AgileBrowser can do. This guide is a follow-up example, where user is introduced to AgileBrowser basic functions via a simple example.

1. Open a model file. Here meego_handset_armv7hl_n900_devel_1_2_deps.txt model is used. Model can be opened from the Model Repository tree (bottom left corner) if models exists there or it can be opened from the locally using 'File' -> 'Open Model File'.

[[File:firstview.png|center]]

2. Then lets take a look what kind of kernel information model holds. Type 'kernel' into search field (text field located top of the screen) and hit enter. This searches the model looking for the elements that have 'kernel' in the name. In this case the result where given in the root level because we didn't gave any further details.

[[File:kernel1.png|center]]

3. Now lets increase the Detail Level to get more detailed view about the 'kernel' search. Increase 'Detail Level' by 2 (Change 'Detail level 1' to 3 in Properties panel located in the top right corner). This action adds two more detail levels to graph.

Browser now shows a good graph about Kernel in chosen model.

[[File:kernel2.png|center]]

4. Lets now take a look at, that what elements/components are using these elements in the graph. So we are interested on what are the incoming dependencies. Select 'incoming' from the Dependencies combobox (located in the same Properties panel than the Detail level).

It automatically draws all the incoming dependencies to kernel search elements.

[[File:kernel3.png|center]]

Then lets take a look that what are the outgoing dependencies for the kernel search. (change 'incoming' to 'outgoing' in Dependencies combobox).

[[File:kernel4.png|center]]

5. Select an element from the graph to get more information about it (model has to contain attributes to get attribute information). If element has some attributes, those are shown in the Info panel (located in the bottom right corner). In this case we selected 'kernel-headers'. Attribute information shows that kernel-headers is under GPLv2 license.

Now we are interested that what kind of licenses does the elements in the graph have. Lets change the coloring to be based on licensing information. Select 'Coloring' to be 'license under the 'Attribute Highlighting' (from the Properties panel again).

This action colors all the elements that have license information. So same licenses are with the same color and so on. This is a good way to get a big picture about some attribute information, in this case about license.

[[File:kernel5.png|center]]

From the graph it's now easy to see what kind of licenses elements have. LegendView shows the matching license based on coloring. Also it's possible to change color by clicking the color from the LegendView.

6. Now if user wants to take a closer look at e.g. 'glibc' -element (this is in the graph), it is possible by double-clicking the element. This action shows the element with the same rules applied to it what we had done before. It shows the element with detail level 4 (this is because double-clicking drills down 1 level), it used automatically license coloring and it shows all the Outgoing dependencies.

[[File:kernel6.png|center]]

== Full User Guide ==

[[/FullUserGuide|Full User Guide]]

= FAQ =

== Search Related ==

=== How to perform basic element search? ===
Basic search can be done by using Search Field located in the top of the application. By typing a string into Search Field it searches all the elements matching to string. Search rules can be modified (to what search string matches) from the 'Find Matches to...' which can be found from the Properties panel located in top right corner.

If using "" in the beginning and in the end of the string, search only returns exact match of the string.

=== How to perform search based on a attribute? (e.g. finding all the elements with GPLv2 license) ===
By typing @license="GPLv2" into the search field, searches all the elements which are including the GPLv2 license. Of course, the license attribute has to be included in the model. Otherwise if not, it returns an empty graph.

If "" marks are removed from the query (@license=GPLv2), search returns also the LGPLv2 licensed elements.

=== Is it possible to combine search queries? ===
Yes. By using logical operations (AND, NOT, OR). For example, query string 'GUI OR Desktop' returns all the elements matching to GUI and also all the elements matching to Desktop. If using operator AND then result is given of both strings can be found from the element.

=== How to search certain element filtering out some area from the scope? ===
This can be done by using operator NOT in the search string. Using search string 'kernel AND NOT "/System"' returns all the kernel named elements which are located somewhere else than under /System.

=== Is it possible to search dependencies between elements? ===
Yes. Also dependency search is possible using Search Field. E.g. search string '"/System" --> "/User Interface"' returns all the dependencies which are from /System to /User Interface. If using just -- between the elements in the search string, search returns all the dependencies between those two elements (from /System to /User Interface and vice verse).

=== How to perform dependency search between elements based on a dependency type? ===
Dependency attribute filtering must be inserted between the -- marks. If using same search string as above but with difference, that it returns just dependencies which are having type of package, the following string must be used: "/System" -package-> "/User Interface".

=== Search query returned an empty graph. What should I do? Is Something wrong? ===
This is a normal behavior when nothing can be found from the model. This means that there is no results to return with given search string.

First user should check typos from the Search Field, then user should check the Matching Criterias from the 'Find Matches to...' (can be found from the Properties panel). If everything looks ok, then model does not contain anything to return.

= Contacts =
[[User:Villeez|Contact: Ville Laitila]]

File:Sf2011-deps.txt

2011-06-28T10:51:46Z

Mythi:

AgileBrowser

2011-06-28T10:48:43Z

Mythi: Add instructions to generate dependency files /* Getting Started */

[[File:header.png]]

[http://wiki.meego.com/images/AgileBrowser.zip Download AgileBrowser installer]

= Introduction =

AgileBrowser is a free architecture management tool. It abstracts and visualizes software models of MeeGo OS. The main focus is to provide easier access to up-to-date architecture information gathered from multiple sources. The models contain stuctural and dependendency information. There are several types of external attributes to be attached to the information. Users of AgileBrowser can navigate, search, highlight with colors, share and export diagrams in various abstraction levels according to their individual needs.

[[File:overview.png|center]]

= Getting Started =

== Installation ==
Installer package is available in this wiki: [[File:AgileBrowser.zip]]

AgileBrowser can be run on Windows, Mac, Linux, etc., anywhere where Java is supported. The most important requirement is that the tool is memory expensive so it is recommended to have 1 GB RAM or fast swapping.

== Dependency file generation ==

To use AgileBrowser, a dependency metadata file is needed. For a quick start, download an example dependency file here.

The following gives instructions to generate the dependency metadata file from scratch.

# Checkout [[https://gitorious.org/meego-architecture/meego-deps-gen meego-deps-gen ]] project
# Get a package list (.packages) from any of the MeeGo images directory
#* Syntax <code><packagename>.<arch> <ver>-<rel></code>
# Get OSS and NON-OSS repodata primary XMLs for the same release
#* Download, unzip and rename as oss.xml and non-oss.xml
# Merge oss.xml and non-oss.xml into primary.xml
#* <code>sh merge-repodata.sh</code>
# Generate dependencies
#* <code>sh create-deps.sh <packagelistfilename>.packages</code>

= User Guide =

There are different guides available. Quick guide is for basic use cases of Agile Browser. In Quick Guide user is introduced to basic functionalities via simple example. Full User Guide contains all the functionalities of the tool.

== Quick Guide ==

It is time to take a closer look what AgileBrowser can do. This guide is a follow-up example, where user is introduced to AgileBrowser basic functions via a simple example.

1. Open a model file. Here meego_handset_armv7hl_n900_devel_1_2_deps.txt model is used. Model can be opened from the Model Repository tree (bottom left corner) if models exists there or it can be opened from the locally using 'File' -> 'Open Model File'.

[[File:firstview.png|center]]

2. Then lets take a look what kind of kernel information model holds. Type 'kernel' into search field (text field located top of the screen) and hit enter. This searches the model looking for the elements that have 'kernel' in the name. In this case the result where given in the root level because we didn't gave any further details.

[[File:kernel1.png|center]]

3. Now lets increase the Detail Level to get more detailed view about the 'kernel' search. Increase 'Detail Level' by 2 (Change 'Detail level 1' to 3 in Properties panel located in the top right corner). This action adds two more detail levels to graph.

Browser now shows a good graph about Kernel in chosen model.

[[File:kernel2.png|center]]

4. Lets now take a look at, that what elements/components are using these elements in the graph. So we are interested on what are the incoming dependencies. Select 'incoming' from the Dependencies combobox (located in the same Properties panel than the Detail level).

It automatically draws all the incoming dependencies to kernel search elements.

[[File:kernel3.png|center]]

Then lets take a look that what are the outgoing dependencies for the kernel search. (change 'incoming' to 'outgoing' in Dependencies combobox).

[[File:kernel4.png|center]]

5. Select an element from the graph to get more information about it (model has to contain attributes to get attribute information). If element has some attributes, those are shown in the Info panel (located in the bottom right corner). In this case we selected 'kernel-headers'. Attribute information shows that kernel-headers is under GPLv2 license.

Now we are interested that what kind of licenses does the elements in the graph have. Lets change the coloring to be based on licensing information. Select 'Coloring' to be 'license under the 'Attribute Highlighting' (from the Properties panel again).

This action colors all the elements that have license information. So same licenses are with the same color and so on. This is a good way to get a big picture about some attribute information, in this case about license.

[[File:kernel5.png|center]]

From the graph it's now easy to see what kind of licenses elements have. LegendView shows the matching license based on coloring. Also it's possible to change color by clicking the color from the LegendView.

6. Now if user wants to take a closer look at e.g. 'glibc' -element (this is in the graph), it is possible by double-clicking the element. This action shows the element with the same rules applied to it what we had done before. It shows the element with detail level 4 (this is because double-clicking drills down 1 level), it used automatically license coloring and it shows all the Outgoing dependencies.

[[File:kernel6.png|center]]

== Full User Guide ==

[[/FullUserGuide|Full User Guide]]

= FAQ =

== Search Related ==

=== How to perform basic element search? ===
Basic search can be done by using Search Field located in the top of the application. By typing a string into Search Field it searches all the elements matching to string. Search rules can be modified (to what search string matches) from the 'Find Matches to...' which can be found from the Properties panel located in top right corner.

If using "" in the beginning and in the end of the string, search only returns exact match of the string.

=== How to perform search based on a attribute? (e.g. finding all the elements with GPLv2 license) ===
By typing @license="GPLv2" into the search field, searches all the elements which are including the GPLv2 license. Of course, the license attribute has to be included in the model. Otherwise if not, it returns an empty graph.

If "" marks are removed from the query (@license=GPLv2), search returns also the LGPLv2 licensed elements.

=== Is it possible to combine search queries? ===
Yes. By using logical operations (AND, NOT, OR). For example, query string 'GUI OR Desktop' returns all the elements matching to GUI and also all the elements matching to Desktop. If using operator AND then result is given of both strings can be found from the element.

=== How to search certain element filtering out some area from the scope? ===
This can be done by using operator NOT in the search string. Using search string 'kernel AND NOT "/System"' returns all the kernel named elements which are located somewhere else than under /System.

=== Is it possible to search dependencies between elements? ===
Yes. Also dependency search is possible using Search Field. E.g. search string '"/System" --> "/User Interface"' returns all the dependencies which are from /System to /User Interface. If using just -- between the elements in the search string, search returns all the dependencies between those two elements (from /System to /User Interface and vice verse).

=== How to perform dependency search between elements based on a dependency type? ===
Dependency attribute filtering must be inserted between the -- marks. If using same search string as above but with difference, that it returns just dependencies which are having type of package, the following string must be used: "/System" -package-> "/User Interface".

=== Search query returned an empty graph. What should I do? Is Something wrong? ===
This is a normal behavior when nothing can be found from the model. This means that there is no results to return with given search string.

First user should check typos from the Search Field, then user should check the Matching Criterias from the 'Find Matches to...' (can be found from the Properties panel). If everything looks ok, then model does not contain anything to return.

= Contacts =
[[User:Villeez|Contact: Ville Laitila]]

Architecture

2011-06-17T12:59:15Z

Mythi: /* Upcoming Features */

== MeeGo Architecture ==

MeeGo architecture team is responsible for defining and managing the MeeGo architecture. MeeGo architecture consists of Core OS layer and number of UX verticals on top the Core OS layer. The architecture team decides which component to use for the functionality needed in MeeGo with the objective of consistency inside the Core OS and to the applications that run above it.

== Team ==

* '''[http://meego.com/users/arjan Arjan van de Ven]''', Chief Architect, responsible for MeeGo architecture
* '''[http://meego.com/users/poussa Sakari Poussa]''', Core OS Architect, responsible for Core OS architecture
* '''[http://meego.com/users/mythi Mikko Ylinen]''', Handset UX Architect, responsible for Handset UX architecture
* '''[http://meego.com/users/sunilsaxena Sunil Saxena]''', Core OS Architect, responsible for Core OS architecture

== Communication ==

* [http://lists.meego.com/listinfo/meego-architecture MeeGo architecture mailing list]

== Process ==

* Architecture team meets once a week. Currently the meetings are not public.
* Agenda and minutes of the meetings will be posted to the meego-architecture mailing list
* Anyone can propose topics to the architecture team agenda
* Architecture topics can and should be discussed on meego-architecture mailing list
* Architecture team is responsible of making the decision in case consensus is not reached

=== Process Improvement Topics ===

* How to make the architecture meetings open. Not all the topics can be open but most can be. Examples of non-open parts includes topics which involves IPR, legal, patent, business, product or schedule sensitive material.

== Documentation ==

* Developer Documentation: APIs, tutorials, videos, examples ([http://developer.meego.com]), to be published soon
* Architecture Documentation: High level architecture pictures and description ([http://meego.com/developers/meego-architecture])
* Developer and Subsystem Documentation: Detailed technical description of each MeeGo subsystem. Guidelines for developers working on MeeGo. ([[Architecture/Documentation]])

== Meetings ==

* [[Architecture/Meetings]] - Meetings - agenda, minutes

== Upcoming Features ==

* PIM Storage in Evolution Data Server (EDS) and email via Camel, SyncEvolution as sync engine
** architecture decision to move towards EDS and Camel [http://lists.meego.com/pipermail/meego-dev/2011-March/481890.html announced]
** planning [[/planning/evolution-data-server|in progress]]

== Tools ==

Architecture tools

* [[AgileBrowser|Architecture navigation tool]]: able to browse meego packages and visually see the dependencies.

Architecture

2011-06-17T12:57:17Z

Mythi: /* Tools */

== MeeGo Architecture ==

MeeGo architecture team is responsible for defining and managing the MeeGo architecture. MeeGo architecture consists of Core OS layer and number of UX verticals on top the Core OS layer. The architecture team decides which component to use for the functionality needed in MeeGo with the objective of consistency inside the Core OS and to the applications that run above it.

== Team ==

* '''[http://meego.com/users/arjan Arjan van de Ven]''', Chief Architect, responsible for MeeGo architecture
* '''[http://meego.com/users/poussa Sakari Poussa]''', Core OS Architect, responsible for Core OS architecture
* '''[http://meego.com/users/mythi Mikko Ylinen]''', Handset UX Architect, responsible for Handset UX architecture
* '''[http://meego.com/users/sunilsaxena Sunil Saxena]''', Core OS Architect, responsible for Core OS architecture

== Communication ==

* [http://lists.meego.com/listinfo/meego-architecture MeeGo architecture mailing list]

== Process ==

* Architecture team meets once a week. Currently the meetings are not public.
* Agenda and minutes of the meetings will be posted to the meego-architecture mailing list
* Anyone can propose topics to the architecture team agenda
* Architecture topics can and should be discussed on meego-architecture mailing list
* Architecture team is responsible of making the decision in case consensus is not reached

=== Process Improvement Topics ===

* How to make the architecture meetings open. Not all the topics can be open but most can be. Examples of non-open parts includes topics which involves IPR, legal, patent, business, product or schedule sensitive material.

== Documentation ==

* Developer Documentation: APIs, tutorials, videos, examples ([http://developer.meego.com]), to be published soon
* Architecture Documentation: High level architecture pictures and description ([http://meego.com/developers/meego-architecture])
* Developer and Subsystem Documentation: Detailed technical description of each MeeGo subsystem. Guidelines for developers working on MeeGo. ([[Architecture/Documentation]])

== Meetings ==

* [[Architecture/Meetings]] - Meetings - agenda, minutes

== Upcoming Features ==

MeeGo Bugzilla lists the following features for MeeGo 1.2. The below proposal are all accepted and are on their way to MeeGo 1.2 release.

* Display backlight and keyboard backlight control: [http://bugs.meego.com/show_bug.cgi?id=5525 5525], [http://bugs.meego.com/show_bug.cgi?id=5526 5526], [http://bugs.meego.com/show_bug.cgi?id=5527 5527], [http://bugs.meego.com/show_bug.cgi?id=5528 5528]
** Proposal 1: Maemo 6 MCE
*** ''MCE provides activity monitoring and notifications via D-Bus, controls display and backlight, ALS reading and display tuning, airplane mode''

* Sharing: [http://bugs.meego.com/show_bug.cgi?id=8179 8179], [http://bugs.meego.com/show_bug.cgi?id=8180 8180], [http://bugs.meego.com/show_bug.cgi?id=8181 8181]
** Proposal 1: Maemo6 Sharing framework
*** ''Sharing framework provides a unified API for sharing files via, e.g., BT, email, web services. It includes webupload engine and an API for transfer UI''

* Qt style APIs (that are not covered by Qt Mobility) for display backlight control, alarm/time, heartbeat, system state, thermal
** Proposal 1: Maemo6 QmSystem
*** ''QmSystem provides Qt style public APIs for various system services that are not covered by Qt Mobility''

* Profiles: [http://bugs.meego.com/show_bug.cgi?id=5771 5771], [http://bugs.meego.com/show_bug.cgi?id=5750 5750], [http://bugs.meego.com/show_bug.cgi?id=2889 2889]
** Proposal 1: Maemo6 profiled
*** ''profiled provides a daemon and libraries to access and control profiles related data in the device. The libprofile (C) and libprofile-qt (Qt) are interfaces for the profile client to connect to the server using D-Bus. The profiled data is stored in ‘ini’ files which can be customized per different releases.''

* Ringtones+feedback: [http://bugs.meego.com/show_bug.cgi?id=2889 2889]
** Proposal 1: Maemo6 NGF (non-graphic feedback)
*** ''The device has functionality to alert user of a call, alarms and notification (SMS, email, chat, system update) events. Events may or may not have a graphical part and it may have different behavior depending on the system state. Example of this is receiving an SMS message when there is no other activity and SMS message during a call. NGF provides a unified API for apps to request logical events. The actions (e.g,. play/show LED+audio+vibra) are combined in NGF and consistent look&feel is provided''.

* PIM Storage in Evolution Data Server (EDS) and email via Camel, SyncEvolution as sync engine
** architecture decision to move towards EDS and Camel [http://lists.meego.com/pipermail/meego-dev/2011-March/481890.html announced]
** planning [[/planning/evolution-data-server|in progress]]

== Tools ==

Architecture tools

* [[AgileBrowser|Architecture navigation tool]]: able to browse meego packages and visually see the dependencies.

Packaging/Guidelines

2011-02-03T14:00:55Z

Mythi: /* Domain/Subsystem based RPM Groups */

= Packaging Guidelines =

Guidelines below were adapted for MeeGo from Moblin, OpenSUSE, Fedora and other distributions.

== Maintaining a Package ==
Every package in MeeGo needs a maintainer (AKA owner, bug owner). Any package without an owner will automatically be nominated for deletion from MeeGo. A package maintainer is responsible for making sure that
* packages are up to date with latest upstream
* packages consistently build in the MeeGo build system and fix build failures when they occur
* package meta data in the RPM spec file is accurate
* the license of the package is correct
* she/he follow upstream for any critical security issues and fix them ASAP
* she/he Provides information about major changes to other packagers and maintainer to allow enough time for fixing compatibility issues

Since the data about ownership of packages is not maintained anywhere right now we are starting to use available meta data fields in the build system to track ownership. This will be better integrated and managed at a later point, but to be able to start somewhere MeeGo will use the bugowner key available for every package. We will start adding the metadata about maintainers (bugowners) in the build system and we will have agrace period for this data to be supplied and added to the build system. After the grace period, packages without maintainer will be reviewed and any packages without a maintainer will be nominated for deletion.

To add yourself as a bugowner of a package, please follow the steps below:
* Update to the most recent osc version (0.129) from the MeeGo tools repository (note: this is essential, since the needed options are not released upstream yet)
* Identify the packages of which you are the ultimate maintainer
* Do the following for every package you maintain in the Trunk:* projects:
<code>
osc reqms --role bugowner <project> <package> -m "I want to own this because I love this package"
</code>
* Your request will be sent and someone in release engineering will approve it

The current status can be seen here: [[Packaging/Maintainers]]

== Package Naming ==
* Dash '-' must be used as the delimiter for name parts.
* Do NOT use an underscore '_', a plus '+', or a period '.' as a delimiter.
* The spec file should be named using the %{name}.spec scheme which should also correspond to the package name within a project in the build system.

== Version and Release ==

Package Versions look like : X.Y.Z-R.B
* X.Y.Z is the 'Version' number - determined by the source package.
* R is the 'Release' number which is automatically incremented by OBS whenever a source/packaging changes (eg a check-in or request acceptance)
* B is the build number which is incremented when the package is rebuilt due to a dependency change.

=== Version ===

The Version field in the spec file is where you should put the current version of the software being packaged.
There are four cases where the version contains non-numeric characters:

* Pre-release packages: Packages released as "pre-release" versions, prior to a "final" version. Example tags include "alpha", "beta", "rc", "cvs", "git", "svn", etc... Details can be found below: Non-Numeric Version.
* Post-release packages: Packages released after a "final" version. These packages contain the same numeric version as the "final" version, but have an additional non-numeric identifier. This mechanism may also be used for packaging only changes to an upstream package.
* Snapshot packages: Packages built from SCM snapshots. These packages could be either "pre" or "post" release packages.

==== Non-Numeric Version ====

We can use letters and tilde into the version tag. We do not use the Release field for this.

Example:
<pre>
Let's assume the following Qt versions:
Qt 4.7.0~beta1
Qt 4.7.0~beta1+git1
Qt 4.7.0~beta2
Qt 4.7.0

Version comparison results:
$ rpmdev-vercmp 4.7.0~beta1 4.7.0~beta1+git1
0:4.7.0~beta1+git1-None is newer

$ rpmdev-vercmp 4.7.0~beta1+git2 4.7.0~beta2
0:4.7.0~beta2-None is newer

$ rpmdev-vercmp 4.7.0~beta2 4.7.0
0:4.7.0-None is newer

Conclusion:
4.7.0~beta1 < 4.7.0~beta1+git1 < 4.7.0~beta2 < 4.7.0
</pre>

Note that the ~ comparison order is specific to MeeGo rpm (http://rpm.org/ticket/56).

=== Release ===

This field is handled by the build system to be able to manage automated builds. The initial setting in the spec file is used by the build system but in many cases it does not need to be changed.

There is no need for the %{dist} macro in the release field. This is also handled directly by the build system.

The release number is set to zero with any version update. It is increased by one with any change in the package.

We can put letters into the version tag, so we do not use the Release field for this. Details can be found above.

If you build the package outside of the OBS or if you copy a package then you will of course not get the correct Release or Build values.

== Tags ==
*The ''Packager'' tag should not be used in spec files. The identities of the packagers are evident from the changelog entries. By not using the ''Packager'' tag, you also avoid seeing bad binaries rebuilt by someone else with your name in the header. See also the '''Maximum RPM definition of the Packager tag''' at [http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html#S3-RPM-INSIDE-PACKAGER-TAG www.rpm.org] . If you need to include information about the packager in the rpms ''you'' built, use <code>%packager</code> in your <code>~/.rpmmacros</code> instead.
*The ''Vendor'' tag should not be used. It is set automatically by the build system.

*Usually, the ''Pre<code></code>Req'' tag should be replaced by plain ''Requires''. For more info, see Maximum RPM snapshot's [http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-FINE-GRAINED fine grained dependencies chapter] .
* The ''Source'' tag documents where to find the upstream sources for the rpm. In most cases this should be a complete URL to the upstream tarball.
=== Summary Tag ===
The summary is a single line string describing the package. The maximum length is 80 characters. It should fit all standard situations and not assume any special context. It should be helpful alone, in alphabetically sorted or unsorted lists of some selected packages, and in alphabetically sorted or unsorted lists of all packages.

It should describe the package's main function and point out any special properties of the package to support the user comparing similar packages. For example, the two words "Web Browser" summarize any web browser, but using additional adjectives (like minimalistic, complex, GNOME, KDE, text-based, fast, or author's) helps characterize a specific package.

The RPM spec file contains only the English version to keep the RPM database small.

*The ''Summary'' tag value should not end in a period. If this bothers you from a grammatical point of view, sit down, take a deep breath, and get over it.

=== Group Tag ===

Valid RPM Groups are:
<pre>
Amusements/Games
Amusements/Graphics
Applications/Archiving
Applications/Communications
Applications/Databases
Applications/Editors
Applications/Emulators
Applications/Engineering
Applications/File
Applications/Internet
Applications/Multimedia
Applications/Productivity
Applications/Publishing
Applications/System
Applications/Text
Development/Debuggers
Development/Languages
Development/Libraries
Development/System
Development/Tools
Documentation
System/Boot
System/Console
System/I18n/Chinese
System/I18n/Japanese
System/I18n/Korean
System/Packages
System/Base
System/Daemons
System/Kernel
System/Libraries
System/Shells
System/X11
System/X11/Fonts
System/X11/Icons
System/GUI/XFCE
System/GUI/Other
System/GUI/GNOME
</pre>

==== Domain/Subsystem based RPM Groups ====

Following the new architecture and the new [http://meego.com/developers/meego-architecture/meego-architecture-domain-view domain view], RPM groups (The Group tag in the RPM) for core packages will be changed to match the domains and any package in the core that is part of one of the domain will have a corresponding group that matches the architecture.

{|
! Domain
! Subsystem
!Groupname
|-
| Communications || Cellular Adaptation || Communications/Cellular Adaptation
|-
| Communications || Cellular Framework || Communications/Cellular Framework
|-
| Communications || Telephony and IM || Communications/Telephony and IM
|-
| Communications || Bluetooth || Communications/Bluetooth
|-
| Communications || Connectivity Adaptation || Communications/Connectivity Adaptation
|-
| Communications || ConnMan || Communications/ConnMan
|-
| Data Management || Content Framework || Data Management/Content Framework
|-
| Development Platform || Platform SDK || Development Platform/Platform SDK
|-
| Essentials || Base Essentials || Essentials/Base Essentials
|-
| Graphics || Font Management || Graphics/Font Management
|-
| Graphics || Display and Graphics Adaptation || Graphics/Display and Graphics Adaptation
|-
| Graphics || Input Adaptation || Graphics/Input Adaptation
|-
| Graphics || Open GL ES || Graphics/Open GL ES
|-
| Graphics || X11 || Graphics/X11
|-
| Kernel || Linux Kernel || Kernel/Linux Kernel
|-
| Location || Location Framework || Location/Location Framework
|-
| Location || Location Adaptation || Location/Location Adaptation
|-
| Multimedia || Audio Adaptation || Multimedia/Audio Adaptation
|-
| Multimedia || Camera Adaptation || Multimedia/Camera Adaptation
|-
| Multimedia || Gstreamer || Multimedia/Gstreamer
|-
| Multimedia || Imaging and Video Adaptation || Multimedia/Imaging and Video Adaptation
|-
| Multimedia || Imaging Codecs || Multimedia/Imaging Codecs
|-
| Multimedia || PulseAudio || Multimedia/PulseAudio
|-
| Multimedia || Sharing || Multimedia/Sharing
|-
| Multimedia || UPnP || Multimedia/UPnP
|-
| Personal Information Management || Backup Framework || Personal Information Management/Backup Framework
|-
| Personal Information Management || Calendar Engine || Personal Information Management/Calendar Engine
|-
| Personal Information Management || Contacts Engine || Personal Information Management/Contacts Engine
|-
| Personal Information Management || Email Engine || Personal Information Management/Email Engine
|-
| Personal Information Management || Synchronization Framework || Personal Information Management/Synchronization Framework
|-
| Qt || Qt || Qt/Qt
|-
| Qt || Qt Mobility || Qt/Qt Mobility
|-
| Qt || Qt WebKit || Qt/Qt WebKit
|-
| Security || Accounts || Security/Accounts
|-
| Security || Certificate Manager || Security/Certificate Manager
|-
| Security || Integrity Protection Framework || Security/Integrity Protection Framework
|-
| Security || Access Control Framework || Security/Access Control Framework
|-
| Security || Single Sign-On || Security/Single Sign-On
|-
| Security || SW Distribution Security || Security/SW Distribution Security
|-
| Security || Security Adaptation || Security/Security Adaptation
|-
| Software Management || Package Manager || Software Management/Package Manager
|-
| System || Context Framework || System/Context Framework
|-
| System || NGF || System/NGF
|-
| System || Resource Policy || System/Resource Policy
|-
| System || Sensor Adaptation || System/Sensor Adaptation
|-
| System || Sensor Framework || System/Sensor Framework
|-
| System || Startup Services || System/Startup Services
|-
| System || System Control || System/System Control
|-
| System || Device Mode Adaptation || System/Device Mode Adaptation
|-
| System || Vibra and Haptics Adaptation || System/Vibra and Haptics Adaptation
|-

|}

=== BuildRoot tag ===
The ''BuildRoot'' value MUST be below <code>%{_tmppath}/</code> and MUST contain at least <code>%{name}</code>, <code>%{version}</code> and <code>%{release}</code>.

The ''recommended'' values for the ''BuildRoot'' tag are (in descending order of preference) :
<pre>
%{_tmppath}/%{name}-%{version}-%{release}-root
</pre>

The BuildRoot tag can be omitted in packages targeting MeeGo only and is handled directly by rpm in MeeGo, for packages that need to run on other distros with older rpm it should be added for backward compatibility.

=== PreReq ===

Packages should not use the PreReq tag. Once upon a time, in dependency loops PreReq used to "win" over the conventional Requires when RPM determined the installation order in a transaction. This is no longer the case.

=== Explicit Requires ===
Packages must not contain explicit ''Requires'' on libraries except when absolutely
necessary. When explicit library ''Requires'' are necessary, there should be a spec file comment justifying it.

We generally rely on rpmbuild to automatically add dependencies on library SONAMEs.
Modern package management tools are capable of resolving such dependencies to determine
the required packages. Explicit dependencies on specific package names may aid the
inexperienced user, who attempts at installing RPM packages manually, however, history
has shown that such dependencies add confusion when library/files are moved from one
package to another, when packages get renamed, when one out of multiple alternative
packages would suffice, and when versioned explicit dependencies become out-of-date and
inaccurate. Additionally, in some cases, old explicit dependencies on package names
require unnecessary updates/rebuilds.

Exemplary rationale for a versioned explicit dependency:
<pre>
# The automatic dependency on libfubar.so.1 is insufficient,
# as we strictly need at least the release that fixes two segfaults.
Requires: libfubar >= 0:1.2.3-7
</pre>

Packagers should revisit an explicit dependency as appropriate to avoid
it becoming inaccurate and superfluous.

=== BuildRequires ===

In package development and testing, please verify that your package is not missing any necessary build dependencies. Having proper build requirements saves the time of all developers and testers as well as build systems because they will not need to search for missing build requirements manually. It is also a safety feature that prevents builds with that would not otherwise fail, but would be missing crucial features. For example, a graphical application may exclude PNG support after its '''configure''' script detects that libpng is not installed.

Before adding Build<code></code>Requires to any package, please be comfortable with [[#Requires| Requires]] .

=== Patches ===
Each problem should be solved in a separate patch. To allow easy maintenance of patches, every patch should have a header providing the following information:

* Authors' names
* [http://meego.com/about/contribution-guidelines/signed-process Signed-off-by] tag
* Detailed description of the fixed problem
* URL of the original source of the patch if any

The name of a patch file consists of:

* The name and version of the source tarball from which the patched file is derived
* Some words that characterize the patch content
* The filename suffix <code class="filename">.patch</code>

Patches are in the unified format ('''diff -u''') and should be applied with 1 strip level in the spec file ('''%patch -p1'''). The only exceptions are the patches obtained from an another primary source site. The original name, suffix, and format is preserved in this case.

Each patch should be compressed with '''bzip2''' if its size is greater than 100kB. The macros <code class="systemitem">%name</code> and <code class="systemitem">%version</code> should be used whenever possible.

Example:

Source: %{name}-%{version}.tar.bz2
Patch0: %{name}-%{version}-autoconf.patch
Patch1: %{name}-%{version}-gcc31.patch

For the patches to be applied, the patches should be mentioned under %setup. For the above example, this could be done as

%setup -q
%patch0 -p1
%patch1 -p1

Patches have to be marked as such in the spec file and should be applied using the internal patch routines available in rpm. Use of alternate patch management system not supported by rpm is not allowed.

=== %clean ===

The %clean section is not required for MeeGo 1.1 and above. Each package for MeeGo 1.0 MUST have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).

== Documentation ==
Any relevant documentation included in the source distribution should be included in the package. Irrelevant documentation include build instructions, the omnipresent ''INSTALL'' file containing generic build instructions, for example, and documentation for non-Linux systems, e.g. ''README.MSDOS''. Pay also attention about which subpackage you include documentation in, for example API documentation belongs in the -devel subpackage, not the main one. Or if there's a lot of documentation, consider putting it into a subpackage. In this case, it is recommended to use <code>*-doc</code> as the subpackage name, and <code>Documentation</code> as the value of the <code>Group</code> tag.

Also, if a package includes something as <code>%doc</code>, it must not affect the runtime of the application. To summarize: If it is in <code>%doc</code>, the program must run properly if it is not present.

== Devel Packages ==
If the software being packaged contains files intended solely for development, those files should be put in a -devel subpackage. The following are examples of file types which should be in -devel:
* Header files (such as .h files)
* Unversioned shared libraries (such as libfoo.so). Versioned shared libraries (such as libfoo.so.3, libfoo.so.3.0.0) should not be in -devel.

A good rule of thumb is if the file is used for development and not needed for the base package to run properly, it should go in -devel.

=== Requiring Base Package ===
Devel packages must require the base package using a fully versioned dependency: <code>Requires: %{name} = %{version}-%{release}</code>.
Usually, subpackages other than -devel should also require the base package using a fully versioned dependency.

=== Pkgconfig Files ===
The placement of pkgconfig(.pc) files depends on their usecase. Since they are almost always used for development purposes, they should be placed in a -devel package.
A reasonable exception is when the main package itself is a development tool not installed in a user runtime, such as gcc or gdb.

== Test Packages ==
Tests should be included in -test subpackage or separate package according to the following guidelines.

[http://wiki.meego.com/Test_Packaging Test Packaging Guidelines]

== Shared Libraries ==
Whenever possible (and feasible), MeeGo Packages containing libraries should build them as shared libraries. In addition, every binary RPM package which contains shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in <code>%post</code> and <code>%postun</code>. If the package has multiple subpackages with libraries, each subpackage should also have a <code>%post/%postun</code> section that calls <code>/sbin/ldconfig</code>. An example of the correct syntax for this is:
<pre>
%post -p /sbin/ldconfig

%postun -p /sbin/ldconfig
</pre>
Note that this specific syntax only works if <code>/sbin/ldconfig</code> is the only call in <code>%post</code> and <code>%postun</code>. If you have additional commands to run during the scriptlet, call <code>/sbin/ldconfig</code> at the beginning of the scriptlet, like this:
<pre>
%post
/sbin/ldconfig
/usr/bin/foo --add

%postun
/sbin/ldconfig
/usr/bin/foo --remove
</pre>

== Configuration files ==

Configuration files must be marked as such in packages.

As a rule of thumb, use <code>%config(noreplace)</code> instead of plain <code>%config</code> unless your best, educated guess is that doing so will break things. In other words, think hard before overwriting local changes in configuration files on package upgrades. An example case when /not/ to use <code>noreplace</code> is when a package's configuration file changes so that the new package revision wouldn't work with the config file from the previous package revision. Whenever plain <code>%config</code> is used, add a brief comment to the specfile explaining why.

Don't use %config or %config(noreplace) under /usr. /usr is deemed to not contain configuration files in MeeGo.

== Initscripts ==

Currently, only SystemV-style initscripts are supported in MeeGo.

== Desktop files ==

If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window. Installed .desktop files MUST follow the [http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html desktop-entry-spec] , paying particular attention to validating correct usage of Name, GenericName, [http://standards.freedesktop.org/menu-spec/latest/apa.html Categories] ,
[http://www.freedesktop.org/Standards/startup-notification-spec StartupNotify]
entries.

=== Icon tag in Desktop Files ===
The icon tag can be specified in two ways:

* Full path to specific icon file:
<code> Icon=/usr/share/pixmaps/comical.png </code>

* Short name without file extension:
<code> Icon=comical </code>

The short name without file extension is preferred, because it allows for icon theming (it assumes .png by default, then tries .svg and finally .xpm), but either method is acceptable.

=== .desktop file creation ===
If the package doesn't already include and install its own .desktop file, you need to make your own. You can do this by including a .desktop file you create as a Source: (such as Source3: %{name}.desktop) or generating it in the spec file. Here are the contents of a sample .desktop file (comical.desktop):

<pre>
[Desktop Entry]
Name=Comical
GenericName=Comic Archive Reader
Comment=Open .cbr & .cbz files
Exec=comical
Icon=comical
Terminal=false
Type=Application
Categories=Graphics;
</pre>

=== desktop-file-install usage ===
It is not simply enough to just include the .desktop file in the package, one MUST run <code>desktop-file-install</code> OR <code>desktop-file-validate</code> in <code>%install</code> (and have <code>BuildRequires: desktop-file-utils</code>), to help ensure .desktop file safety and spec-compliance. <code>desktop-file-install</code> MUST be used if the package does not install the file or there are changes desired to the .desktop file (such as add/removing categories, etc). <code>desktop-file-validate</code> MAY be used instead if the .desktop file's content/location does not need modification. Here are some examples of
usage:

<pre>
desktop-file-install \
--dir=${RPM_BUILD_ROOT}%{_datadir}/applications \
%{SOURCE3}
</pre>

<pre>
desktop-file-install \
--add-category="AudioVideo" \
--delete-original \
--dir=%{buildroot}%{_datadir}/applications \
%{buildroot}/%{_datadir}/foo.desktop
</pre>

<pre>
desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop
</pre>

== Macros ==
=== Using %{buildroot} and %{optflags} vs $RPM_BUILD_ROOT and $RPM_OPT_FLAGS ===
There are two styles of defining the rpm Build Root and Optimization Flags in a spec file:

{| border="1"
|-
| ||macro style || variable style
|-
|Build Root||%{buildroot}||$RPM_BUILD_ROOT
|-
|Opt. Flags||%{optflags}||$RPM_OPT_FLAGS
|}

There is very little value in choosing one style over the other, since they will resolve to the same values in all scenarios. You should pick a style and use it consistently throughout your packaging.

Mixing the two styles, while valid, is bad from a QA and usability point of view, and should not be done in MeeGo packages.

== Handling Locale Files ==

If the package includes translations, add
<pre>
BuildRequires: gettext
</pre>
If you don't, your package could fail to generate translation files in the buildroot.

MeeGo includes an rpm macro called <code>%find_lang</code>. This macro will locate all of the locale files that belong to your package (by name), and put this list in a file. You can then use that file to include all of the locales. <code>%find_lang</code> should be run in the %install section of your spec file, after all of the files have been installed into the buildroot. The correct syntax for <code>%find_lang</code> is usually:
<pre>
%find_lang %{name}
</pre>
In some cases, the application may use a different "name" for its locales. You may have to look at the locale files and see what they are named. If they are named <code>myapp.mo</code>, then you will need to pass <code>myapp</code> to <code>%find_lang</code> instead of <code>%{name</code>}.
After <code>%find_lang</code> is run, it will generate a file in the active directory (by default, the top level of the source dir). This file will be named based on what you passed as the option to the <code>%find_lang</code> macro. Usually, it will be named <code>%{name}.lang</code>. You should then use this file in the <code>%files</code> list to include the locales detected by <code>%find_lang</code>. To do this, you should include it with the -f parameter to <code>%files</code>.
<pre>
%files -f %{name}.lang
%defattr(-,root,root,-)
%{_bindir}/foobar
...
</pre>
If you are already using the -f parameter for the <code>%files</code> section where the locales should live, just append the contents of <code>%{name}.lang</code> to the end of the file that you are already using with -f. (Note that only one file may be used with <code>%files -f</code>.)

Here is an example of proper usage of <code>%find_lang</code>, in <code>foo.spec</code>:

<pre>
...
%prep
%setup -q

%build
%configure --with-cheese
make %{?_smp_mflags}

%install
make DESTDIR=%{buildroot} install
%find_lang %{name}

%clean
rm -rf %{buildroot}

%files -f %{name}.lang
%defattr(-,root,root,-)
%doc LICENSE README
%{_bindir}/foobar

</pre>

=== Why do we need to use %find_lang? ===

Using <code>%find_lang</code> helps keep the spec file simple, and helps avoid several other packaging mistakes.

* Packages that use <code>%{_datadir}/*</code> to grab all the locale files in one line also grab ownership of the locale directories, which is not permitted.
* Most packages that have locales have lots of locales. Using <code>%find_lang</code> is much easier in the spec file than having to do:
<pre>
%{_datadir}/locale/ar/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/be/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/cs/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/de/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/es/LC_MESSAGES/%{name}.mo
...
</pre>
* As new locale files appear in later package revisions, <code>%find_lang</code> will automatically include them when it is run, preventing you from having to update the spec any more than is necessary.

Keep in mind that usage of <code>%find_lang</code> in packages containing locales is a MUST.

== Scriptlets ==
Great care should be taken when using scriptlets in MeeGo packages. If scriptlets are used, those scriptlets must be sane.

=== Scriptlets requirements ===
Do not use the <code>Requires(pre,post)</code> style notation for scriptlet dependencies, because of two bugs in RPM. Instead, they should be split like this:
<pre>
Requires(pre): ...
Requires(post): ...
</pre>
For more information, see [http://www.redhat.com/archives/fedora-devel-list/2004-April/msg00674.html www.redhat.com] .

=== Running scriptlets only in certain situations ===
When the rpm command executes the scriptlets in a package it indicates if the action preformed is an install, erase, upgrade or reinstall by passing an integer argument to the script in question according to the following:
<pre>
install erase upgrade reinstall
%pre 1 - 2 2
%post 1 - 2 2
%preun - 0 1 -
%postun - 0 1 -
</pre>
This means that for example a package that installs an init script with the <code>chkconfig</code> command should uninstall it only on erase and not upgrade with the following snippet:
<pre>
%preun
if [ $1 -eq 0 ] ; then
/sbin/chkconfig --del %{name}
fi
</pre>
See also <code>/usr/share/doc/rpm-*/triggers</code>, which gives a more formal, generalized definition about the integer value(s) passed to various scripts.

=== Scriplets are only allowed to write in certain directories ===
Build scripts of packages (%prep, %build, %install, %check and %clean) may only alter files (create, modify, delete) under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process) according to the following matrix

{| border="1"
|-
| || /tmp, /var/tmp, $TMPDIR, %{_tmppath} || %{_builddir} || %{buildroot}
|-
|%prep || yes || yes || no
|-
|%build || yes || yes || no
|-
|%install || yes || yes || yes
|-
|%check || yes || yes || no
|-
|%clean || yes || yes || yes
|}

Further clarification: That should hold true irrespective of the builder's uid.

== Use of Epochs ==
The Epoch tag in RPM is to be used only as a last resort, and should be avoided whenever possible. However, it is sometimes necessary to use an Epoch to handle upstream versioning changes or to ease transition from third party repositories.

== Writing a package from scratch ==

See [[Spectacle]]

Spectacle is a great tool for straightforward packages, and we have many of those, hundreds, many of those packages already have been using spectacle happily for a while now. Generally, the 80/20 rule applies here, almost 80% of packages in MeeGo can be converted to this format, probably around 20% will need to stay as is for various reasons.

Spectacle in general helps a lot when you have a package that does:
* configure
* make
* make install

and especially useful when for example you have to manage many build dependencies and patches or for common packaging of perl/python/X packages that usually follows the same packaging work flow. We have plans to add lots of nice features to make packaging easier and more fun with spectacle.

While spectacle has many advanced options to cover all kind of corner cases, it should not be used for complex packages that would require lots of customization, especially now that we support multiple architectures and where we need to apply code and custom scripts to support different scenarios.

Spectacle provides scripts to convert spec files to spectacle, those try to do their best but you SHOULD never just take the output as is and rely on the script, a review of the output is necessary, otherwise you might end up with lots of duplication in the spec file. This is the most common mistake, developers are relying on the output of the conversion script, basically picking some spec file from another distro and converting it. This can lead to major disasters in some cases.

So to summarize:
* It is NOT mandatory to use spectacle
* If you try to convert and find yourself spending more than a few minutes on a package, then probably there is something wrong and you should not be using that or you should RTFM.
* Use it with care, especially when you first import the data from existing spec files or when you first create your YAML file
* Your distro maintainer might send you a note that certain packages you are maintaining could be converted to spectacle easily, but she/he should not reject your package because it does not use spectacle.
* If you find yourself forced to edit the spec file manually for some reason, then either:
** your package is not suitable to be used with spectacle
** or you might want to ask for a feature to support that special case

== Modifying existing Packages ==

If you base a new package on an existing non-MeeGo package, make sure you verify its correctness of the package and the spec file and to understand exactly what has been done to package the software exactly. Do not submit a package without knowing what those strange, but innocent-looking commands do.

In particular, you should

* ensure that original tarballs are self-contained pristine tarballs. The tarball should not contain symlinks that reference outside the tarball root directory
* verify any sources and patches and remove patches or sources that:
** are related to platforms we do not support (example: sparc, ia64, ppc, ...)
** Implement features we do not support (example: selinux)
** Read every patch and understand what it does, if it is needed, put an explanation in the header justifying why the patch is needed.
* verify that the license stated in the spec file matches the actual license of the software,
* skim the summary and description for typos and oddities (see Summary and description ),
* make sure that the correct build root is used,
* ensure that macro usage is consistent and that the macros are available in MeeGo (see Macros ).

Keep old changelog entries to credit the original authors. Entries that are several years old or refer to ancient versions of the software may be erased. If you end up doing radical changes and re-write most of the spec file anyway, feel free to start the changelog from scratch. In other words, use your best judgement.

== Changelogs ==

This section describes the MeeGo policy for RPM changelogs. (Original changelogs included in the original source are not affected by this policy.)

Please consider that a "normal end user with some technical skills" should be able to read and understand an RPM changelog. Changelog entries have to be in reverse chronological order: newer change log entries are listed above older entries, with the first entry being the most recent.

Please bear in mind theat MeeGo changelogs will be automatically parsed to prepare distribution release notes and to report on bugs and CVEs and malformed entries may not be read correctly.

=== General information ===

* MeeGo uses a separate file for package changes which is similar to a debian changelog file. This file is named as the spec file, but ends in *.changes instead of *.spec
* Entries in the changes file should have the following structure:
<pre>
* dow mmm dd yyyy Name Goes Here <your@email.com> - [version]
- comment
- comment

</pre>

Note the following exceptions are noted through observation:
* version is often omitted (such as: alsa-utils 1.0.15-1 -> 1.0.16-1)
* there are multiple changelog entries per version (such as: alsa-utils 1.0.19)
* the hyphen between email and version is often omitted (such as: alsa-utils)
* spaces between name and <email> are omitted (such as: Zhang, Qiang Z<qiang.z.zhang@intel.com> nano)
* name is sometimes omitted (such as: bitstream-vera-fonts nicolas.mailhot at laposte.net)
* <email> is sometimes omitted (such as: binutils Jim Kingdon)
This wide variation in formats makes automation tasks harder than they should be. Please use the correct format.

=== External References ===

Each external reference (bug numbers etc) should be of the form:
"(" + external reference code + bug number +")"

Currently defined:
* MeeGo Bugs : BMC#
* MeeGo Features: FEA#
* Common Vulnerability / Exposure : CVE

==== Bug Numbers in the change log ====

During maintenance of a distribution, every change has to be marked with the correct bug number. Normally this has to be an number from https://bugzilla.meego.com/. Add an entry with bugzilla number and a short description of the bug-summary. For example:
- Removed invalid desktop Category "Application" (BMC#4654).
- Symlink icon to pixmaps dir (BMC#2108)
- Added gnome-ui-properties to control-center (BMC#1960).

New packages related to new features will refer to the corresponding bug number in bugzilla, preceded with an FEA. For example:
- Adding Qt Contacts support FEA#8011

==== CVE numbers in change log ====

As with bug numbers: Add a short description (normally the CVE summary should be enough), the Bugzilla and the CVE number to the changelog entry. Examples:
- Add gdk-pixbuf-226710.patch (BMC#226710), and (CVE-2007-0010).
- More XPM fixes: (CVE-2005-2975) xpm too many colors DoS (BMC#129642)
- fix ~/.dmrc symlink attack (BMC#180704), (CVE-2006-2449)

=== Spec File changes ===
Be as precise as possible! This is especially important if you remove something from the spec file.

* Removing original source code must be declared in spec file with a comment ("useful for FreeBSD only" for example) - not necessary to repeat the comment in specfile.
* Extra commands (for example during %install) can be illustrated with a short comment in spec file
* Adding/Removing packages from Requires/Provides must be described in the changelog

=== Source Code changes ===

Document the most important changes but limit verbosity.

* look into the source changelog and pick up the most important changes for the distribution (changes for other operation systems are not important). What has changed in the new version, usually in the level of detail of a NEWS file, the change log files are usually too long. More than '''10-15 lines''' shouldn't be necessary to describe the most important changes.
* arrange the original changes behind the version update information. Example:
- Update to 1.3.2:
+ fixes memory leak in import function
+ new API command: unlock_client()
+ the following bugs are closed by this new upstream release:
++ ............ [MGN:332]
++ .............[MGN:337]
- split of devel package
* If upstream does not provide a meaningful change log, then only do best effort. Don't waste too much time over it.
* If the upstream tarball really has not changed except for the version number, just the version number in the change log would be fine. Same goes for packages just containing some graphics or theming (unless upstream already provides something that fits). If the upstream changes just consists of "updated translation" or "several bug fixes" even that can be sufficient for a changelog entry (unless these bug fixes contain something you find worth mentioning).

== Packaging Static Libraries ==
Packages including libraries should exclude static libs as far as possible (eg by configuring with ''--disable-static''). Static libraries should only be included in exceptional circumstances. Applications linking against libraries should as far as possible link against shared libraries not static versions.

Libtool archives, ''foo.la'' files, should not be included. Packages using libtool will install these by default even if you configure with ''--disable-static'', so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove *.la files without modifying the program. In most cases it is fairly easy to work with upstream to fix these issues. Note that if you are updating a library in a stable release (not devel) and the package already contains *.la files, removing the *.la files should be treated as an API/ABI change -- ie: Removing them changes the interface that the library gives to the rest of the world and should not be undertaken lightly.

=== Packaging Static Libraries ===
* In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists.

* We want to be able to track which packages are using static libraries (so we can find which packages need to be rebuilt if a security flaw in a static library is fixed, for instance). There are two scenarios in which static libraries are packaged:
# '''Static libraries and shared libraries.''' In this case, the static libraries must be placed in a ''*-static'' subpackage. Separating the static libraries from the other development files in ''*-devel'' allow us to track this usage by checking which packages <code>BuildRequire</code> the ''*-static'' package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries.
# '''Static libraries only.''' When a package only provides static libraries you can place all the static library files in the ''*-devel'' subpackage. When doing this you also must have a virtual Provide for the ''*-static'' package:
<pre>%package devel
Provides: foo-static = %{version}-%{release}</pre>

Packages which explicitly need to link against the static version must <code>BuildRequire: foo-static</code>, so that the usage can be tracked.

* If (and only if) a package has shared libraries which require static libraries to be functional, the static libraries can be included in the ''*-devel'' subpackage. The devel subpackage must have a virtual Provide for the ''*-static'' package, and packages dependent on it must <code>BuildRequire</code> the ''*-static'' package.

=== Staticly Linking Executables ===
* Static linkage is a special exception and should be decided on a case-by-case basis. The packager must provide rationale for linking statically, including precedences where available, to release engineering for approval.

[[Category:Packaging]]

Quality/Compliance/MeeGo Compliance Specification

2011-01-21T14:43:03Z

Mythi: /* Package Management */ Remove details about package payload compressions. The first sentence already says format should follow MeeGo Reference Implementation.

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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 MeeGo Profile layers on top of MeeGo 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 MeeGo Profile or, more generally, to MeeGo Core, to target multiple profiles.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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.

== 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 MeeGo 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 MeeGo Reference Implementation and fails on another implementation, it is the responsibility of the failing implementation to resolve the conflict.

=== CPU Architectures ===

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 ===

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

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

There are no assurances that an application constructed for a particular version will run on any earlier version.

= Platform Compatibility =

== Requirements ==

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

It is permissible for a system implementation to provide alternative (''additional'' or ''supplementary'') 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).

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 Reference Implementation and SHALL NOT replace or omit MeeGo Core or MeeGo Profile components. They SHALL NOT repackage the software such that individual files appear in different binary package names than those used in the MeeGo Reference Implementation. Modifications to the MeeGo 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 MeeGo Reference Implementation. A package MAY be compiled to use a specific instruction set, to optimize for the target device, as long as the ABI remains compliant to MeeGo Reference Implementation.

== 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:

* SHALL <nowiki>''provide''</nowiki> (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 MeeGo Core packages consistent across all MeeGo compliant distributions.

== Additional System Components ==

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

* MUST NOT overwrite MeeGo Core components

* MUST NOT conflict with file system namespace of MeeGo ABI (commands and utilities)

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> for ARM), when run in the default environment, shall load all shared libraries required for compliance from the paths provided by the MeeGo Reference Implementation. That is, except in debug and other special cases, required libraries must not be overridden by alternative versions.

=== MeeGo 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 Reference Implementation.

=== Default Shell Interpreter ===

The default shell interpreter <code>/bin/sh</code> 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 by the MeeGo Reference Implementation.

== Package Management ==

A compliant system shall supply the RPM Package Manager (RPM), as provided by the MeeGo Reference Implementation, and support installation of all compliant RPM packages, as created by the corresponding version 4.8 RPM build tool. The system shall support installation and updating of packages from RPM repositories using PackageKit.

== 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 =

== Requirements ==

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.

== 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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

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

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-21T14:19:19Z

Mythi: /* MeeGo Core Components */ Formatting changes only.

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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 MeeGo Profile layers on top of MeeGo 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 MeeGo Profile or, more generally, to MeeGo Core, to target multiple profiles.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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.

== 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 MeeGo 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 MeeGo Reference Implementation and fails on another implementation, it is the responsibility of the failing implementation to resolve the conflict.

=== CPU Architectures ===

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 ===

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

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

There are no assurances that an application constructed for a particular version will run on any earlier version.

= Platform Compatibility =

== Requirements ==

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

It is permissible for a system implementation to provide alternative (''additional'' or ''supplementary'') 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).

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 Reference Implementation and SHALL NOT replace or omit MeeGo Core or MeeGo Profile components. They SHALL NOT repackage the software such that individual files appear in different binary package names than those used in the MeeGo Reference Implementation. Modifications to the MeeGo 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 MeeGo Reference Implementation. A package MAY be compiled to use a specific instruction set, to optimize for the target device, as long as the ABI remains compliant to MeeGo Reference Implementation.

== 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:

* SHALL <nowiki>''provide''</nowiki> (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 MeeGo Core packages consistent across all MeeGo compliant distributions.

== Additional System Components ==

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

* MUST NOT overwrite MeeGo Core components

* MUST NOT conflict with file system namespace of MeeGo ABI (commands and utilities)

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> for ARM), when run in the default environment, shall load all shared libraries required for compliance from the paths provided by the MeeGo Reference Implementation. That is, except in debug and other special cases, required libraries must not be overridden by alternative versions.

=== MeeGo 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 Reference Implementation.

=== Default Shell Interpreter ===

The default shell interpreter <code>/bin/sh</code> 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 by the MeeGo Reference Implementation.

== Package Management ==

A compliant system shall supply the RPM Package Manager (RPM), as provided by the MeeGo 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 RPM repositories using PackageKit.

== 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 =

== Requirements ==

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.

== 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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

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

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-21T14:18:21Z

Mythi: /* Platform Source Code Modification Policy */ Clarify compiler options sentence. Harmonize terms.

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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 MeeGo Profile layers on top of MeeGo 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 MeeGo Profile or, more generally, to MeeGo Core, to target multiple profiles.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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.

== 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 MeeGo 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 MeeGo Reference Implementation and fails on another implementation, it is the responsibility of the failing implementation to resolve the conflict.

=== CPU Architectures ===

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 ===

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

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

There are no assurances that an application constructed for a particular version will run on any earlier version.

= Platform Compatibility =

== Requirements ==

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

It is permissible for a system implementation to provide alternative (''additional'' or ''supplementary'') 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).

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 Reference Implementation and SHALL NOT replace or omit MeeGo Core or MeeGo Profile components. They SHALL NOT repackage the software such that individual files appear in different binary package names than those used in the MeeGo Reference Implementation. Modifications to the MeeGo 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 MeeGo Reference Implementation. A package MAY be compiled to use a specific instruction set, to optimize for the target device, as long as the ABI remains compliant to MeeGo Reference Implementation.

== 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:

* SHALL <nowiki>''provide''</nowiki> (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

<code>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 MeeGo Core packages consistent across all MeeGo compliant distributions.</code>

== Additional System Components ==

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

* MUST NOT overwrite MeeGo Core components

* MUST NOT conflict with file system namespace of MeeGo ABI (commands and utilities)

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> for ARM), when run in the default environment, shall load all shared libraries required for compliance from the paths provided by the MeeGo Reference Implementation. That is, except in debug and other special cases, required libraries must not be overridden by alternative versions.

=== MeeGo 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 Reference Implementation.

=== Default Shell Interpreter ===

The default shell interpreter <code>/bin/sh</code> 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 by the MeeGo Reference Implementation.

== Package Management ==

A compliant system shall supply the RPM Package Manager (RPM), as provided by the MeeGo 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 RPM repositories using PackageKit.

== 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 =

== Requirements ==

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.

== 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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

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

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-14T12:56:46Z

Mythi: Harmonize terms.

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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 MeeGo Profile layers on top of MeeGo 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 MeeGo Profile or, more generally, to MeeGo Core, to target multiple profiles.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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.

== 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 MeeGo 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 MeeGo Reference Implementation and fails on another implementation, it is the responsibility of the failing implementation to resolve the conflict.

=== CPU Architectures ===

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 ===

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

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

There are no assurances that an application constructed for a particular version will run on any earlier version.

= Platform Compatibility =

== Requirements ==

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

It is permissible for a system implementation to provide alternative (''additional'' or ''supplementary'') 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).

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 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 MeeGo Reference Implementation. Modifications to the MeeGo 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.

== 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:

* SHALL <nowiki>''provide''</nowiki> (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

<code>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 MeeGo Core packages consistent across all MeeGo compliant distributions.</code>

== Additional System Components ==

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

* MUST NOT overwrite MeeGo Core components

* MUST NOT conflict with file system namespace of MeeGo ABI (commands and utilities)

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> for ARM), when run in the default environment, shall load all shared libraries required for compliance from the paths provided by the MeeGo Reference Implementation. That is, except in debug and other special cases, required libraries must not be overridden by alternative versions.

=== MeeGo 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 Reference Implementation.

=== Default Shell Interpreter ===

The default shell interpreter <code>/bin/sh</code> 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 by the MeeGo Reference Implementation.

== Package Management ==

A compliant system shall supply the RPM Package Manager (RPM), as provided by the MeeGo 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 RPM repositories using PackageKit.

== 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 =

== Requirements ==

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.

== 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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

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

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-14T12:33:11Z

Mythi: /* Core Shared Libraries */ Add MeeGo in subsection title.

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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.

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

=== CPU Architectures ===

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 ===

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

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

There are no assurances that an application constructed for a particular version will run on any earlier version.

= Platform Compatibility =

== Requirements ==

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

It is permissible for a system implementation to provide alternative (''additional'' or ''supplementary'') 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).

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.

== 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:

* SHALL <nowiki>''provide''</nowiki> (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

<code>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.</code>

== Additional System Components ==

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

* MUST NOT overwrite MeeGo Core components

* MUST NOT conflict with file system namespace of MeeGo ABI (commands and utilities)

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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.

=== MeeGo 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.

=== Default Shell Interpreter ===

The default shell interpreter <code>/bin/sh</code> 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 by the MeeGo Reference Implementation.

== Package Management ==

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 RPM repositories using PackageKit.

== 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 =

== Requirements ==

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.

== 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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

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

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-14T12:31:22Z

Mythi: /* Requirements */ Fix spec. internal reference.

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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.

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

=== CPU Architectures ===

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 ===

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

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

There are no assurances that an application constructed for a particular version will run on any earlier version.

= Platform Compatibility =

== Requirements ==

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

It is permissible for a system implementation to provide alternative (''additional'' or ''supplementary'') 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).

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.

== 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:

* SHALL <nowiki>''provide''</nowiki> (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

<code>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.</code>

== Additional System Components ==

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

* MUST NOT overwrite MeeGo Core components

* MUST NOT conflict with file system namespace of MeeGo ABI (commands and utilities)

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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.

=== Default Shell Interpreter ===

The default shell interpreter <code>/bin/sh</code> 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 by the MeeGo Reference Implementation.

== Package Management ==

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 RPM repositories using PackageKit.

== 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 =

== Requirements ==

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.

== 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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

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

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-14T12:21:09Z

Mythi: /* Use of APIs Provided by Platform */ Remove inconsistency.

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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.

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

=== CPU Architectures ===

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 ===

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

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

There are no assurances that an application constructed for a particular version will run on any earlier version.

= Platform Compatibility =

== Requirements ==

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 (''additional'' or ''supplementary'') 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).

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.

== 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:

* SHALL <nowiki>''provide''</nowiki> (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

<code>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.</code>

== Additional System Components ==

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

* MUST NOT overwrite MeeGo Core components

* MUST NOT conflict with file system namespace of MeeGo ABI (commands and utilities)

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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.

=== Default Shell Interpreter ===

The default shell interpreter <code>/bin/sh</code> 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 by the MeeGo Reference Implementation.

== Package Management ==

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 RPM repositories using PackageKit.

== 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 =

== Requirements ==

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.

== 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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

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

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-14T12:17:30Z

Mythi: Restructure subsections to improve readability. Better structure to separate application and platform compliance within the specification.

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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.

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

=== CPU Architectures ===

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 ===

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

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

There are no assurances that an application constructed for a particular version will run on any earlier version.

= Platform Compatibility =

== Requirements ==

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 (''additional'' or ''supplementary'') 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).

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.

== 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:

* SHALL <nowiki>''provide''</nowiki> (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

<code>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.</code>

== Additional System Components ==

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

* MUST NOT overwrite MeeGo Core components

* MUST NOT conflict with file system namespace of MeeGo ABI (commands and utilities)

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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.

=== Default Shell Interpreter ===

The default shell interpreter <code>/bin/sh</code> 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 by the MeeGo Reference Implementation.

== Package Management ==

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 RPM repositories using PackageKit.

== 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 =

== Requirements ==

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.

== 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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.

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

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-14T12:01:52Z

Mythi: /* System Implementation Compliance */ Harmonize terms. Platform Compliance is used in other places.

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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 ==

=== Platform 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 (''additional'' or ''supplementary'') 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.

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.

== 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:

* SHALL <nowiki>''provide''</nowiki> (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

<code>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.</code>

== Additional System Components ==

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

* MUST NOT overwrite MeeGo Core components

* MUST NOT conflict with file system namespace of MeeGo ABI (commands and utilities)

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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.

=== Default Shell Interpreter ===

The default shell interpreter <code>/bin/sh</code> 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 by the MeeGo Reference Implementation.

== Package Management ==

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 RPM repositories using PackageKit.

== 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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.

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

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-14T11:59:57Z

Mythi: /* Definitions */ Fix typesetting/copy-paste error.

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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 (''additional'' or ''supplementary'') 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.

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.

== 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:

* SHALL <nowiki>''provide''</nowiki> (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

<code>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.</code>

== Additional System Components ==

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

* MUST NOT overwrite MeeGo Core components

* MUST NOT conflict with file system namespace of MeeGo ABI (commands and utilities)

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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.

=== Default Shell Interpreter ===

The default shell interpreter <code>/bin/sh</code> 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 by the MeeGo Reference Implementation.

== Package Management ==

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 RPM repositories using PackageKit.

== 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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.

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

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-14T11:56:24Z

Mythi: /* System Implementation Compliance */ Clarify alternative implementations to be additional/supplementary

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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 (''additional'' or ''supplementary'') 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.

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.

== 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:

* SHALL <nowiki>''provide''</nowiki> (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

<code>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.</code>

== Additional System Components ==

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

* MUST NOT overwrite MeeGo Core components

* MUST NOT conflict with file system namespace of MeeGo ABI (commands and utilities)

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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.

=== Default Shell Interpreter ===

The default shell interpreter <code>/bin/sh</code> 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 by the MeeGo Reference Implementation.

== Package Management ==

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 RPM repositories using PackageKit.

== 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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.

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

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-14T11:48:21Z

Mythi: /* Core Components */ Change subsection to MeeGo Core Components

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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.

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.

== 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:

* SHALL <nowiki>''provide''</nowiki> (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

<code>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.</code>

== Additional System Components ==

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

* MUST NOT overwrite MeeGo Core components

* MUST NOT conflict with file system namespace of MeeGo ABI (commands and utilities)

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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.

=== Default Shell Interpreter ===

The default shell interpreter <code>/bin/sh</code> 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 by the MeeGo Reference Implementation.

== Package Management ==

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 RPM repositories using PackageKit.

== 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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.

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

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-14T11:46:26Z

Mythi: /* Package Management */ s/yum/RPM/

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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.

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.

== 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 <nowiki>''provide''</nowiki> (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

<code>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.</code>

== Additional System Components ==

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

* MUST NOT overwrite MeeGo Core components

* MUST NOT conflict with file system namespace of MeeGo ABI (commands and utilities)

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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.

=== Default Shell Interpreter ===

The default shell interpreter <code>/bin/sh</code> 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 by the MeeGo Reference Implementation.

== Package Management ==

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 RPM repositories using PackageKit.

== 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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.

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

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-10T16:22:27Z

Mythi: Forgot to make Core Components a subsection with == (was ===)

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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.

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.

== 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 <nowiki>''provide''</nowiki> (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

<code>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.</code>

== Additional System Components ==

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

* MUST NOT overwrite MeeGo Core components

* MUST NOT conflict with file system namespace of MeeGo ABI (commands and utilities)

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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.

=== Default Shell Interpreter ===

The default shell interpreter <code>/bin/sh</code> 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 by the MeeGo Reference Implementation.

== Package Management ==

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.

== 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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.

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

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-10T16:21:32Z

Mythi: Move subsections under 'platform compliance' to improve readability

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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.

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.

=== 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 <nowiki>''provide''</nowiki> (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

<code>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.</code>

== Additional System Components ==

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

* MUST NOT overwrite MeeGo Core components

* MUST NOT conflict with file system namespace of MeeGo ABI (commands and utilities)

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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.

=== Default Shell Interpreter ===

The default shell interpreter <code>/bin/sh</code> 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 by the MeeGo Reference Implementation.

== Package Management ==

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.

== 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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.

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

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-10T16:13:59Z

Mythi: Move commands and utilities under 'platform compliance' (better place)

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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.

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 (commands and utilities)

== 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 <nowiki>''provide''</nowiki> (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

<code>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.</code>

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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.

=== Default Shell Interpreter ===

The default shell interpreter <code>/bin/sh</code> 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 by the MeeGo 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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.

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

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-10T16:01:23Z

Mythi: Add MeeGo API a requirement for Platform implementations. Give no guarantee for Platform API.

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories for Platform Compliance:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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.

== References ==


* Native Platform Graphics Interface [http://www.khronos.org/registry/egl/specs/eglspec.1.3.pdf 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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.

'''Platform API''' – the complete set of programming interfaces defined for MeeGo Core.

'''Repackaging''' – MeeGo Core packages may not be repackaged. This means the <code>%files</code> 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.

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 <nowiki>''provide''</nowiki> (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

<code>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.</code>

== ABI and API ==

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

=== MeeGo API ===

Implementations must support MeeGo API. The MeeGo API consists of the following:

* Qt 4.7 [ [[#Qt47]] ]
* Qt Mobility 1.0 [ [[#QtMob]] ]
* OpenGL ES 2.0 [ [[#OGLES]] ]

=== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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.

=== Use of APIs Provided by Platform ===

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.

=== 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 <code>/bin/sh</code> 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 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-10T14:22:43Z

Mythi: Fix subsection mismatch against the .pdf version

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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 <code>%files</code> 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 <nowiki>''provide''</nowiki> (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

<code>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.</code>

== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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 <code>/bin/sh</code> 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-10T13:47:08Z

Mythi: Introduction: make chapter a bit more high level intro

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

* Other names and brands may be claimed as the property of others.
</code>

= Introduction =

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.

== Scope ==

This specification sets forth two separate component categories:

* MeeGo Core: a core set of operating system components (or <nowiki>''stack''</nowiki>), 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 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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 <code>%files</code> 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 <nowiki>''provide''</nowiki> (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

<code>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.</code>

== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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 <code>/bin/sh</code> 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-10T13:36:51Z

Mythi: Dependencies: system components -> MeeGo Core components. Change MAY NOT to MUST NOT for dependencies to features outside this specification.

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

* Other names and brands may be claimed as the property of others.
</code>

= 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 <nowiki>''stack''</nowiki>), 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 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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 <code>%files</code> 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 <nowiki>''provide''</nowiki> (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

<code>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.</code>

== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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, <code>com.ovi.appname</code>).

=== Dependencies ===

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.

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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 <code>/bin/sh</code> 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2011-01-10T12:54:08Z

Mythi: References section: remove links which are not used in the document.

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

* Other names and brands may be claimed as the property of others.
</code>

= 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 <nowiki>''stack''</nowiki>), 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 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* 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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* Qt Reference Documentation, version 4.7 [http://apidocs.meego.com/qt4.7/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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 <code>%files</code> 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 <nowiki>''provide''</nowiki> (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

<code>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.</code>

== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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, <code>com.ovi.appname</code>).

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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 <code>/bin/sh</code> 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2010-12-23T12:09:07Z

Mythi: Remove WRT from the specification.

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

* Other names and brands may be claimed as the property of others.
</code>

= 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 <nowiki>''stack''</nowiki>), 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 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* GStreamer 0.10 [http://apidocs.meego.com/platform/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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* MeeGo Touch Framework [http://apidocs.meego.com/mtf/ http://apidocs.meego.com/mtf/]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* PulseAudio 0.9.21 [http://apidocs.meego.com/platform/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/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 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 <code>%files</code> 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 <nowiki>''provide''</nowiki> (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

<code>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.</code>

== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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, <code>com.ovi.appname</code>).

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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 <code>/bin/sh</code> 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Quality/Compliance/MeeGo Compliance Specification

2010-12-23T12:05:02Z

Mythi: Draft Version 1.0.99.5 (Wiki page based on the .pdf version)

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

* Other names and brands may be claimed as the property of others.
</code>

= 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 <nowiki>''stack''</nowiki>), 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 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 http://refspecs.linuxfoundation.org/elf/elf.pdf]


* GStreamer 0.10 [http://apidocs.meego.com/platform/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 http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB‐Core‐generic/LSB‐Core‐generic.html]


* MeeGo Touch Framework [http://apidocs.meego.com/mtf/ http://apidocs.meego.com/mtf/]


* Desktop Notifications Specification 0.9 [http://www.galago‐project.org/specs/notification/0.9 http://www.galago‐project.org/specs/notification/0.9]


* OpenGL ES 2.X [http://www.khronos.org/opengles/2_X http://www.khronos.org/opengles/2_X]


* PulseAudio 0.9.21 [http://apidocs.meego.com/platform/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/ http://apidocs.meego.com/qt4.7/]


* Qt Mobility Project APIS [http://apidocs.meego.com/qtmobility/ 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 http://www.ietf.org/rfc/rfc2119.txt]


* W3C Widget Packaging and Configuration specification [http://www.w3.org/TR/widgets http://www.w3.org/TR/widgets]

== 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 <code>%files</code> 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 <nowiki>''provide''</nowiki> (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

<code>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.</code>

== 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 (<code>/lib/ld-linux.so.2</code> for Atom and <code>/lib/ld-linux.so.3</code> 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, with the exception of Web RunTime packages, which MAY use the native WGT 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, <code>com.ovi.appname</code>).

=== 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:
:: <code>$ rpm –q –-file filename</code>

* List all files installed by a package:
:: <code>$ rpm –ql packagename</code>

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 <code>/opt/packagename/</code> and, if necessary to the <code>/etc/opt/packagename/</code> and <code>/var/opt/packagename/</code> directories. System wide configuration files shall be placed in the <code>/etc/opt/packagename</code> directory rather than directly in <code>/etc</code> , 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 <code>/var/opt/packagename</code> directory rather than directly in <code>/var</code> , unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the <code>~/.config/packagename</code> 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 <code>.desktop</code> file shall be installed under <code>/usr/share/applications</code>, 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 <code>.desktop</code> 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 <code>/bin/sh</code> 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.

== Web Run Time (WRT) Applications ==

=== Runtime Environment ===

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.

=== Packaging and Installation ===
Web Runtime applications are bundled as wgt packages (see [ [[#WGT]] ]). These are installed on the target system using a tool called <code>widgetinstaller</code>, which is part of the <code>qt-web-runtime</code> package and available on all MeeGo‐compliant distributions. Web Runtime applications (<code>wgt</code> 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 <code>widgetinstaller</code> program with the <code>wgt</code> 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.

= 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 <code>libnotify</code> 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 ==

<code>(not copied)</code>

Packaging/Guidelines

2010-12-21T09:44:19Z

Mythi: /* Domain/Subsystem based RPM Groups */

= Packaging Guidelines =

Guidelines below were adapted for MeeGo from Moblin, OpenSUSE, Fedora and other distributions.

== Maintaining a Package ==
Every package in MeeGo needs a maintainer (AKA owner, bug owner). Any package without an owner will automatically be nominated for deletion from MeeGo. A package maintainer is responsible for making sure that
* packages are up to date with latest upstream
* packages consistently build in the MeeGo build system and fix build failures when they occur
* package meta data in the RPM spec file is accurate
* the license of the package is correct
* she/he follow upstream for any critical security issues and fix them ASAP
* she/he Provides information about major changes to other packagers and maintainer to allow enough time for fixing compatibility issues

Since the data about ownership of packages is not maintained anywhere right now we are starting to use available meta data fields in the build system to track ownership. This will be better integrated and managed at a later point, but to be able to start somewhere MeeGo will use the bugowner key available for every package. We will start adding the metadata about maintainers (bugowners) in the build system and we will have agrace period for this data to be supplied and added to the build system. After the grace period, packages without maintainer will be reviewed and any packages without a maintainer will be nominated for deletion.

To add yourself as a bugowner of a package, please follow the steps below:
* Update to the most recent osc version (0.129) from the MeeGo tools repository (note: this is essential, since the needed options are not released upstream yet)
* Identify the packages of which you are the ultimate maintainer
* Do the following for every package you maintain in the Trunk:* projects:
<code>
osc reqms --role bugowner <project> <package> -m "I want to own this because I love this package"
</code>
* Your request will be sent and someone in release engineering will approve it

== Package Naming ==
* Dash '-' must be used as the delimiter for name parts.
* Do NOT use an underscore '_', a plus '+', or a period '.' as a delimiter.
* The spec file should be named using the %{name}.spec scheme which should also correspond to the package name within a project in the build system.

== Version and Release ==

Package Versions look like : X.Y.Z-R.B
* X.Y.Z is the 'Version' number - determined by the source package.
* R is the 'Release' number which is automatically incremented by OBS whenever a source/packaging changes (eg a check-in or request acceptance)
* B is the build number which is incremented when the package is rebuilt due to a dependency change.

=== Version ===

The Version field in the spec file is where you should put the current version of the software being packaged.
There are four cases where the version contains non-numeric characters:

* Pre-release packages: Packages released as "pre-release" versions, prior to a "final" version. Example tags include "alpha", "beta", "rc", "cvs", "git", "svn", etc... Details can be found below: Non-Numeric Version.
* Post-release packages: Packages released after a "final" version. These packages contain the same numeric version as the "final" version, but have an additional non-numeric identifier. This mechanism may also be used for packaging only changes to an upstream package.
* Snapshot packages: Packages built from SCM snapshots. These packages could be either "pre" or "post" release packages.

==== Non-Numeric Version ====

We can use letters and tilde into the version tag. We do not use the Release field for this.

Example:
<pre>
Let's assume the following Qt versions:
Qt 4.7.0~beta1
Qt 4.7.0~beta1+git1
Qt 4.7.0~beta2
Qt 4.7.0

Version comparison results:
$ rpmdev-vercmp 4.7.0~beta1 4.7.0~beta1+git1
0:4.7.0~beta1+git1-None is newer

$ rpmdev-vercmp 4.7.0~beta1+git2 4.7.0~beta2
0:4.7.0~beta2-None is newer

$ rpmdev-vercmp 4.7.0~beta2 4.7.0
0:4.7.0-None is newer

Conclusion:
4.7.0~beta1 < 4.7.0~beta1+git1 < 4.7.0~beta2 < 4.7.0
</pre>

Note that the ~ comparison order is specific to MeeGo rpm (http://rpm.org/ticket/56).

=== Release ===

This field is handled by the build system to be able to manage automated builds. The initial setting in the spec file is used by the build system but in many cases it does not need to be changed.

There is no need for the %{dist} macro in the release field. This is also handled directly by the build system.

The release number is set to zero with any version update. It is increased by one with any change in the package.

We can put letters into the version tag, so we do not use the Release field for this. Details can be found above.

If you build the package outside of the OBS or if you copy a package then you will of course not get the correct Release or Build values.

== Tags ==
*The ''Packager'' tag should not be used in spec files. The identities of the packagers are evident from the changelog entries. By not using the ''Packager'' tag, you also avoid seeing bad binaries rebuilt by someone else with your name in the header. See also the '''Maximum RPM definition of the Packager tag''' at [http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html#S3-RPM-INSIDE-PACKAGER-TAG www.rpm.org] . If you need to include information about the packager in the rpms ''you'' built, use <code>%packager</code> in your <code>~/.rpmmacros</code> instead.
*The ''Vendor'' tag should not be used. It is set automatically by the build system.

*Usually, the ''Pre<code></code>Req'' tag should be replaced by plain ''Requires''. For more info, see Maximum RPM snapshot's [http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-FINE-GRAINED fine grained dependencies chapter] .
* The ''Source'' tag documents where to find the upstream sources for the rpm. In most cases this should be a complete URL to the upstream tarball.
=== Summary Tag ===
The summary is a single line string describing the package. The maximum length is 80 characters. It should fit all standard situations and not assume any special context. It should be helpful alone, in alphabetically sorted or unsorted lists of some selected packages, and in alphabetically sorted or unsorted lists of all packages.

It should describe the package's main function and point out any special properties of the package to support the user comparing similar packages. For example, the two words "Web Browser" summarize any web browser, but using additional adjectives (like minimalistic, complex, GNOME, KDE, text-based, fast, or author's) helps characterize a specific package.

The RPM spec file contains only the English version to keep the RPM database small.

*The ''Summary'' tag value should not end in a period. If this bothers you from a grammatical point of view, sit down, take a deep breath, and get over it.

=== Group Tag ===

Valid RPM Groups are:
<pre>
Amusements/Games
Amusements/Graphics
Applications/Archiving
Applications/Communications
Applications/Databases
Applications/Editors
Applications/Emulators
Applications/Engineering
Applications/File
Applications/Internet
Applications/Multimedia
Applications/Productivity
Applications/Publishing
Applications/System
Applications/Text
Development/Debuggers
Development/Languages
Development/Libraries
Development/System
Development/Tools
Documentation
System/Boot
System/Console
System/I18n/Chinese
System/I18n/Japanese
System/I18n/Korean
System/Packages
System/Base
System/Daemons
System/Kernel
System/Libraries
System/Shells
System/X11
System/X11/Fonts
System/X11/Icons
System/GUI/XFCE
System/GUI/Other
System/GUI/GNOME
</pre>

==== Domain/Subsystem based RPM Groups ====

Following the new architecture and the new [http://meego.com/developers/meego-architecture/meego-architecture-domain-view domain view], RPM groups (The Group tag in the RPM) for core packages will be changed to match the domains and any package in the core that is part of one of the domain will have a corresponding group that matches the architecture.

{|
! Domain
! Subsystem
!Groupname
| Communications || Cellular Adaptation || Communications/Cellular Adaptation
|-
| Communications || Cellular Framework || Communications/Cellular Framework
|-
| Communications || Telephony and IM || Communications/Telephony and IM
|-
| Communications || Bluetooth || Connectivity/Bluetooth
|-
| Communications || Connectivity Adaptation || Communications/Connectivity Adaptation
|-
| Communications || ConnMan || Communications/ConnMan
|-
| Data Management || Content Framework || Data Management/Content Framework
|-
| Development Platform || Platform SDK || Development Platform/Platform SDK
|-
| Essentials || Base Essentials || Essentials/Base Essentials
|-
| Graphics || Font Management || Graphics/Font Management
|-
| Graphics || Display and Graphics Adaptation || Graphics/Display and Graphics Adaptation
|-
| Graphics || Input Adaptation || Graphics/Input Adaptation
|-
| Graphics || Open GL ES || Graphics/Open GL ES
|-
| Graphics || X11 || Graphics/X11
|-
| Kernel || Linux Kernel || Kernel/Linux Kernel
|-
| Location || Location Framework || Location/Location Framework
|-
| Location || Location Adaptation || Location/Location Adaptation
|-
| Multimedia || Audio Adaptation || Multimedia/Audio Adaptation
|-
| Multimedia || Camera Adaptation || Multimedia/Camera Adaptation
|-
| Multimedia || Gstreamer || Multimedia/Gstreamer
|-
| Multimedia || Imaging and Video Adaptation || Multimedia/Imaging and Video Adaptation
|-
| Multimedia || Imaging Codecs || Multimedia/Imaging Codecs
|-
| Multimedia || PulseAudio || Multimedia/PulseAudio
|-
| Multimedia || Sharing || Multimedia/Sharing
|-
| Multimedia || UPnP || Multimedia/UPnP
|-
| Personal Information Management || Backup Framework || Personal Information Management/Backup Framework
|-
| Personal Information Management || Calendar Engine || Personal Information Management/Calendar Engine
|-
| Personal Information Management || Contacts Engine || Personal Information Management/Contacts Engine
|-
| Personal Information Management || Email Engine || Personal Information Management/Email Engine
|-
| Personal Information Management || Synchronization Framework || Personal Information Management/Synchronization Framework
|-
| Qt || Qt || Qt/Qt
|-
| Qt || Qt Mobility || Qt/Qt Mobility
|-
| Qt || Qt WebKit || Qt/Qt WebKit
|-
| Security || Accounts || Security/Accounts
|-
| Security || Certificate Manager || Security/Certificate Manager
|-
| Security || Integrity Protection Framework || Security/Integrity Protection Framework
|-
| Security || Access Control Framework || Security/Access Control Framework
|-
| Security || Single Sign-On || Security/Single Sign-On
|-
| Security || SW Distribution Security || Security/SW Distribution Security
|-
| Security || Security Adaptation || Security/Security Adaptation
|-
| Software Management || Package Manager || Software Management/Package Manager
|-
| System || Context Framework || System/Context Framework
|-
| System || NGF || System/NGF
|-
| System || Resource Policy || System/Resource Policy
|-
| System || Sensor Adaptation || System/Sensor Adaptation
|-
| System || Sensor Framework || System/Sensor Framework
|-
| System || Startup Services || System/Startup Services
|-
| System || System Control || System/System Control
|-
| System || Device Mode Adaptation || System/Device Mode Adaptation
|-
| System || Vibra and Haptics Adaptation || System/Vibra and Haptics Adaptation
|-

|}

=== BuildRoot tag ===
The ''BuildRoot'' value MUST be below <code>%{_tmppath}/</code> and MUST contain at least <code>%{name}</code>, <code>%{version}</code> and <code>%{release}</code>.

The ''recommended'' values for the ''BuildRoot'' tag are (in descending order of preference) :
<pre>
%{_tmppath}/%{name}-%{version}-%{release}-root
</pre>

The BuildRoot tag can be omitted in packages targeting MeeGo only and is handled directly by rpm in MeeGo, for packages that need to run on other distros with older rpm it should be added for backward compatibility.

=== PreReq ===

Packages should not use the PreReq tag. Once upon a time, in dependency loops PreReq used to "win" over the conventional Requires when RPM determined the installation order in a transaction. This is no longer the case.

=== Explicit Requires ===
Packages must not contain explicit ''Requires'' on libraries except when absolutely
necessary. When explicit library ''Requires'' are necessary, there should be a spec file comment justifying it.

We generally rely on rpmbuild to automatically add dependencies on library SONAMEs.
Modern package management tools are capable of resolving such dependencies to determine
the required packages. Explicit dependencies on specific package names may aid the
inexperienced user, who attempts at installing RPM packages manually, however, history
has shown that such dependencies add confusion when library/files are moved from one
package to another, when packages get renamed, when one out of multiple alternative
packages would suffice, and when versioned explicit dependencies become out-of-date and
inaccurate. Additionally, in some cases, old explicit dependencies on package names
require unnecessary updates/rebuilds.

Exemplary rationale for a versioned explicit dependency:
<pre>
# The automatic dependency on libfubar.so.1 is insufficient,
# as we strictly need at least the release that fixes two segfaults.
Requires: libfubar >= 0:1.2.3-7
</pre>

Packagers should revisit an explicit dependency as appropriate to avoid
it becoming inaccurate and superfluous.

=== BuildRequires ===

In package development and testing, please verify that your package is not missing any necessary build dependencies. Having proper build requirements saves the time of all developers and testers as well as build systems because they will not need to search for missing build requirements manually. It is also a safety feature that prevents builds with that would not otherwise fail, but would be missing crucial features. For example, a graphical application may exclude PNG support after its '''configure''' script detects that libpng is not installed.

Before adding Build<code></code>Requires to any package, please be comfortable with [[#Requires| Requires]] .

=== Patches ===
Each problem should be solved in a separate patch. To allow easy maintenance of patches, every patch should have a header providing the following information:

* Authors' names
* [http://meego.com/about/contribution-guidelines/signed-process Signed-off-by] tag
* Detailed description of the fixed problem
* URL of the original source of the patch if any

The name of a patch file consists of:

* The name and version of the source tarball from which the patched file is derived
* Some words that characterize the patch content
* The filename suffix <code class="filename">.patch</code>

Patches are in the unified format ('''diff -u''') and should be applied with 1 strip level in the spec file ('''%patch -p1'''). The only exceptions are the patches obtained from an another primary source site. The original name, suffix, and format is preserved in this case.

Each patch should be compressed with '''bzip2''' if its size is greater than 100kB. The macros <code class="systemitem">%name</code> and <code class="systemitem">%version</code> should be used whenever possible.

Example:

Source: %{name}-%{version}.tar.bz2
Patch0: %{name}-%{version}-autoconf.patch
Patch1: %{name}-%{version}-gcc31.patch

For the patches to be applied, the patches should be mentioned under %setup. For the above example, this could be done as

%setup -q
%patch0 -p1
%patch1 -p1

Patches have to be marked as such in the spec file and should be applied using the internal patch routines available in rpm. Use of alternate patch management system not supported by rpm is not allowed.

=== %clean ===

The %clean section is not required for MeeGo 1.1 and above. Each package for MeeGo 1.0 MUST have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).

== Documentation ==
Any relevant documentation included in the source distribution should be included in the package. Irrelevant documentation include build instructions, the omnipresent ''INSTALL'' file containing generic build instructions, for example, and documentation for non-Linux systems, e.g. ''README.MSDOS''. Pay also attention about which subpackage you include documentation in, for example API documentation belongs in the -devel subpackage, not the main one. Or if there's a lot of documentation, consider putting it into a subpackage. In this case, it is recommended to use <code>*-doc</code> as the subpackage name, and <code>Documentation</code> as the value of the <code>Group</code> tag.

Also, if a package includes something as <code>%doc</code>, it must not affect the runtime of the application. To summarize: If it is in <code>%doc</code>, the program must run properly if it is not present.

== Devel Packages ==
If the software being packaged contains files intended solely for development, those files should be put in a -devel subpackage. The following are examples of file types which should be in -devel:
* Header files (such as .h files)
* Unversioned shared libraries (such as libfoo.so). Versioned shared libraries (such as libfoo.so.3, libfoo.so.3.0.0) should not be in -devel.

A good rule of thumb is if the file is used for development and not needed for the base package to run properly, it should go in -devel.

=== Requiring Base Package ===
Devel packages must require the base package using a fully versioned dependency: <code>Requires: %{name} = %{version}-%{release}</code>.
Usually, subpackages other than -devel should also require the base package using a fully versioned dependency.

=== Pkgconfig Files ===
The placement of pkgconfig(.pc) files depends on their usecase. Since they are almost always used for development purposes, they should be placed in a -devel package.
A reasonable exception is when the main package itself is a development tool not installed in a user runtime, such as gcc or gdb.

== Test Packages ==
Tests should be included in -test subpackage or separate package according to the following guidelines.

[http://wiki.meego.com/Test_Packaging Test Packaging Guidelines]

== Shared Libraries ==
Whenever possible (and feasible), MeeGo Packages containing libraries should build them as shared libraries. In addition, every binary RPM package which contains shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in <code>%post</code> and <code>%postun</code>. If the package has multiple subpackages with libraries, each subpackage should also have a <code>%post/%postun</code> section that calls <code>/sbin/ldconfig</code>. An example of the correct syntax for this is:
<pre>
%post -p /sbin/ldconfig

%postun -p /sbin/ldconfig
</pre>
Note that this specific syntax only works if <code>/sbin/ldconfig</code> is the only call in <code>%post</code> and <code>%postun</code>. If you have additional commands to run during the scriptlet, call <code>/sbin/ldconfig</code> at the beginning of the scriptlet, like this:
<pre>
%post
/sbin/ldconfig
/usr/bin/foo --add

%postun
/sbin/ldconfig
/usr/bin/foo --remove
</pre>

== Configuration files ==

Configuration files must be marked as such in packages.

As a rule of thumb, use <code>%config(noreplace)</code> instead of plain <code>%config</code> unless your best, educated guess is that doing so will break things. In other words, think hard before overwriting local changes in configuration files on package upgrades. An example case when /not/ to use <code>noreplace</code> is when a package's configuration file changes so that the new package revision wouldn't work with the config file from the previous package revision. Whenever plain <code>%config</code> is used, add a brief comment to the specfile explaining why.

Don't use %config or %config(noreplace) under /usr. /usr is deemed to not contain configuration files in MeeGo.

== Initscripts ==

Currently, only SystemV-style initscripts are supported in MeeGo.

== Desktop files ==

If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window. Installed .desktop files MUST follow the [http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html desktop-entry-spec] , paying particular attention to validating correct usage of Name, GenericName, [http://standards.freedesktop.org/menu-spec/latest/apa.html Categories] ,
[http://www.freedesktop.org/Standards/startup-notification-spec StartupNotify]
entries.

=== Icon tag in Desktop Files ===
The icon tag can be specified in two ways:

* Full path to specific icon file:
<code> Icon=/usr/share/pixmaps/comical.png </code>

* Short name without file extension:
<code> Icon=comical </code>

The short name without file extension is preferred, because it allows for icon theming (it assumes .png by default, then tries .svg and finally .xpm), but either method is acceptable.

=== .desktop file creation ===
If the package doesn't already include and install its own .desktop file, you need to make your own. You can do this by including a .desktop file you create as a Source: (such as Source3: %{name}.desktop) or generating it in the spec file. Here are the contents of a sample .desktop file (comical.desktop):

<pre>
[Desktop Entry]
Name=Comical
GenericName=Comic Archive Reader
Comment=Open .cbr & .cbz files
Exec=comical
Icon=comical
Terminal=false
Type=Application
Categories=Graphics;
</pre>

=== desktop-file-install usage ===
It is not simply enough to just include the .desktop file in the package, one MUST run <code>desktop-file-install</code> OR <code>desktop-file-validate</code> in <code>%install</code> (and have <code>BuildRequires: desktop-file-utils</code>), to help ensure .desktop file safety and spec-compliance. <code>desktop-file-install</code> MUST be used if the package does not install the file or there are changes desired to the .desktop file (such as add/removing categories, etc). <code>desktop-file-validate</code> MAY be used instead if the .desktop file's content/location does not need modification. Here are some examples of
usage:

<pre>
desktop-file-install \
--dir=${RPM_BUILD_ROOT}%{_datadir}/applications \
%{SOURCE3}
</pre>

<pre>
desktop-file-install \
--add-category="AudioVideo" \
--delete-original \
--dir=%{buildroot}%{_datadir}/applications \
%{buildroot}/%{_datadir}/foo.desktop
</pre>

<pre>
desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop
</pre>

== Macros ==
=== Using %{buildroot} and %{optflags} vs $RPM_BUILD_ROOT and $RPM_OPT_FLAGS ===
There are two styles of defining the rpm Build Root and Optimization Flags in a spec file:

{| border="1"
|-
| ||macro style || variable style
|-
|Build Root||%{buildroot}||$RPM_BUILD_ROOT
|-
|Opt. Flags||%{optflags}||$RPM_OPT_FLAGS
|}

There is very little value in choosing one style over the other, since they will resolve to the same values in all scenarios. You should pick a style and use it consistently throughout your packaging.

Mixing the two styles, while valid, is bad from a QA and usability point of view, and should not be done in MeeGo packages.

== Handling Locale Files ==

If the package includes translations, add
<pre>
BuildRequires: gettext
</pre>
If you don't, your package could fail to generate translation files in the buildroot.

MeeGo includes an rpm macro called <code>%find_lang</code>. This macro will locate all of the locale files that belong to your package (by name), and put this list in a file. You can then use that file to include all of the locales. <code>%find_lang</code> should be run in the %install section of your spec file, after all of the files have been installed into the buildroot. The correct syntax for <code>%find_lang</code> is usually:
<pre>
%find_lang %{name}
</pre>
In some cases, the application may use a different "name" for its locales. You may have to look at the locale files and see what they are named. If they are named <code>myapp.mo</code>, then you will need to pass <code>myapp</code> to <code>%find_lang</code> instead of <code>%{name</code>}.
After <code>%find_lang</code> is run, it will generate a file in the active directory (by default, the top level of the source dir). This file will be named based on what you passed as the option to the <code>%find_lang</code> macro. Usually, it will be named <code>%{name}.lang</code>. You should then use this file in the <code>%files</code> list to include the locales detected by <code>%find_lang</code>. To do this, you should include it with the -f parameter to <code>%files</code>.
<pre>
%files -f %{name}.lang
%defattr(-,root,root,-)
%{_bindir}/foobar
...
</pre>
If you are already using the -f parameter for the <code>%files</code> section where the locales should live, just append the contents of <code>%{name}.lang</code> to the end of the file that you are already using with -f. (Note that only one file may be used with <code>%files -f</code>.)

Here is an example of proper usage of <code>%find_lang</code>, in <code>foo.spec</code>:

<pre>
...
%prep
%setup -q

%build
%configure --with-cheese
make %{?_smp_mflags}

%install
make DESTDIR=%{buildroot} install
%find_lang %{name}

%clean
rm -rf %{buildroot}

%files -f %{name}.lang
%defattr(-,root,root,-)
%doc LICENSE README
%{_bindir}/foobar

</pre>

=== Why do we need to use %find_lang? ===

Using <code>%find_lang</code> helps keep the spec file simple, and helps avoid several other packaging mistakes.

* Packages that use <code>%{_datadir}/*</code> to grab all the locale files in one line also grab ownership of the locale directories, which is not permitted.
* Most packages that have locales have lots of locales. Using <code>%find_lang</code> is much easier in the spec file than having to do:
<pre>
%{_datadir}/locale/ar/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/be/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/cs/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/de/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/es/LC_MESSAGES/%{name}.mo
...
</pre>
* As new locale files appear in later package revisions, <code>%find_lang</code> will automatically include them when it is run, preventing you from having to update the spec any more than is necessary.

Keep in mind that usage of <code>%find_lang</code> in packages containing locales is a MUST.

== Scriptlets ==
Great care should be taken when using scriptlets in MeeGo packages. If scriptlets are used, those scriptlets must be sane.

=== Scriptlets requirements ===
Do not use the <code>Requires(pre,post)</code> style notation for scriptlet dependencies, because of two bugs in RPM. Instead, they should be split like this:
<pre>
Requires(pre): ...
Requires(post): ...
</pre>
For more information, see [http://www.redhat.com/archives/fedora-devel-list/2004-April/msg00674.html www.redhat.com] .

=== Running scriptlets only in certain situations ===
When the rpm command executes the scriptlets in a package it indicates if the action preformed is an install, erase, upgrade or reinstall by passing an integer argument to the script in question according to the following:
<pre>
install erase upgrade reinstall
%pre 1 - 2 2
%post 1 - 2 2
%preun - 0 1 -
%postun - 0 1 -
</pre>
This means that for example a package that installs an init script with the <code>chkconfig</code> command should uninstall it only on erase and not upgrade with the following snippet:
<pre>
%preun
if [ $1 -eq 0 ] ; then
/sbin/chkconfig --del %{name}
fi
</pre>
See also <code>/usr/share/doc/rpm-*/triggers</code>, which gives a more formal, generalized definition about the integer value(s) passed to various scripts.

=== Scriplets are only allowed to write in certain directories ===
Build scripts of packages (%prep, %build, %install, %check and %clean) may only alter files (create, modify, delete) under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process) according to the following matrix

{| border="1"
|-
| || /tmp, /var/tmp, $TMPDIR, %{_tmppath} || %{_builddir} || %{buildroot}
|-
|%prep || yes || yes || no
|-
|%build || yes || yes || no
|-
|%install || yes || yes || yes
|-
|%check || yes || yes || no
|-
|%clean || yes || yes || yes
|}

Further clarification: That should hold true irrespective of the builder's uid.

== Use of Epochs ==
The Epoch tag in RPM is to be used only as a last resort, and should be avoided whenever possible. However, it is sometimes necessary to use an Epoch to handle upstream versioning changes or to ease transition from third party repositories.

== Writing a package from scratch ==

See [[Spectacle]]

Spectacle is a great tool for straightforward packages, and we have many of those, hundreds, many of those packages already have been using spectacle happily for a while now. Generally, the 80/20 rule applies here, almost 80% of packages in MeeGo can be converted to this format, probably around 20% will need to stay as is for various reasons.

Spectacle in general helps a lot when you have a package that does:
* configure
* make
* make install

and especially useful when for example you have to manage many build dependencies and patches or for common packaging of perl/python/X packages that usually follows the same packaging work flow. We have plans to add lots of nice features to make packaging easier and more fun with spectacle.

While spectacle has many advanced options to cover all kind of corner cases, it should not be used for complex packages that would require lots of customization, especially now that we support multiple architectures and where we need to apply code and custom scripts to support different scenarios.

Spectacle provides scripts to convert spec files to spectacle, those try to do their best but you SHOULD never just take the output as is and rely on the script, a review of the output is necessary, otherwise you might end up with lots of duplication in the spec file. This is the most common mistake, developers are relying on the output of the conversion script, basically picking some spec file from another distro and converting it. This can lead to major disasters in some cases.

So to summarize:
* It is NOT mandatory to use spectacle
* If you try to convert and find yourself spending more than a few minutes on a package, then probably there is something wrong and you should not be using that or you should RTFM.
* Use it with care, especially when you first import the data from existing spec files or when you first create your YAML file
* Your distro maintainer might send you a note that certain packages you are maintaining could be converted to spectacle easily, but she/he should not reject your package because it does not use spectacle.
* If you find yourself forced to edit the spec file manually for some reason, then either:
** your package is not suitable to be used with spectacle
** or you might want to ask for a feature to support that special case

== Modifying existing Packages ==

If you base a new package on an existing non-MeeGo package, make sure you verify its correctness of the package and the spec file and to understand exactly what has been done to package the software exactly. Do not submit a package without knowing what those strange, but innocent-looking commands do.

In particular, you should

* ensure that original tarballs are self-contained pristine tarballs. The tarball should not contain symlinks that reference outside the tarball root directory
* verify any sources and patches and remove patches or sources that:
** are related to platforms we do not support (example: sparc, ia64, ppc, ...)
** Implement features we do not support (example: selinux)
** Read every patch and understand what it does, if it is needed, put an explanation in the header justifying why the patch is needed.
* verify that the license stated in the spec file matches the actual license of the software,
* skim the summary and description for typos and oddities (see Summary and description ),
* make sure that the correct build root is used,
* ensure that macro usage is consistent and that the macros are available in MeeGo (see Macros ).

Keep old changelog entries to credit the original authors. Entries that are several years old or refer to ancient versions of the software may be erased. If you end up doing radical changes and re-write most of the spec file anyway, feel free to start the changelog from scratch. In other words, use your best judgement.

== Changelogs ==

This section describes the MeeGo policy for RPM changelogs. (Original changelogs included in the original source are not affected by this policy.)

Please consider that a "normal end user with some technical skills" should be able to read and understand an RPM changelog. Changelog entries have to be in reverse chronological order: newer change log entries are listed above older entries, with the first entry being the most recent.

Please bear in mind theat MeeGo changelogs will be automatically parsed to prepare distribution release notes and to report on bugs and CVEs and malformed entries may not be read correctly.

=== General information ===

* MeeGo uses a separate file for package changes which is similar to a debian changelog file. This file is named as the spec file, but ends in *.changes instead of *.spec
* Entries in the changes file should have the following structure:
<pre>
* dow mmm dd yyyy Name Goes Here <your@email.com> - [version]
- comment
- comment

</pre>

Note the following exceptions are noted through observation:
* version is often omitted (such as: alsa-utils 1.0.15-1 -> 1.0.16-1)
* there are multiple changelog entries per version (such as: alsa-utils 1.0.19)
* the hyphen between email and version is often omitted (such as: alsa-utils)
* spaces between name and <email> are omitted (such as: Zhang, Qiang Z<qiang.z.zhang@intel.com> nano)
* name is sometimes omitted (such as: bitstream-vera-fonts nicolas.mailhot at laposte.net)
* <email> is sometimes omitted (such as: binutils Jim Kingdon)
This wide variation in formats makes automation tasks harder than they should be. Please use the correct format.

=== External References ===

Each external reference (bug numbers etc) should be of the form:
"(" + external reference code + bug number +")"

Currently defined:
* MeeGo Bugs : BMC#
* MeeGo Features: FEA#
* Common Vulnerability / Exposure : CVE

==== Bug Numbers in the change log ====

During maintenance of a distribution, every change has to be marked with the correct bug number. Normally this has to be an number from https://bugzilla.meego.com/. Add an entry with bugzilla number and a short description of the bug-summary. For example:
- Removed invalid desktop Category "Application" (BMC#4654).
- Symlink icon to pixmaps dir (BMC#2108)
- Added gnome-ui-properties to control-center (BMC#1960).

New packages related to new features will refer to the corresponding bug number in bugzilla, preceded with an FEA. For example:
- Adding Qt Contacts support FEA#8011

==== CVE numbers in change log ====

As with bug numbers: Add a short description (normally the CVE summary should be enough), the Bugzilla and the CVE number to the changelog entry. Examples:
- Add gdk-pixbuf-226710.patch (BMC#226710), and (CVE-2007-0010).
- More XPM fixes: (CVE-2005-2975) xpm too many colors DoS (BMC#129642)
- fix ~/.dmrc symlink attack (BMC#180704), (CVE-2006-2449)

=== Spec File changes ===
Be as precise as possible! This is especially important if you remove something from the spec file.

* Removing original source code must be declared in spec file with a comment ("useful for FreeBSD only" for example) - not necessary to repeat the comment in specfile.
* Extra commands (for example during %install) can be illustrated with a short comment in spec file
* Adding/Removing packages from Requires/Provides must be described in the changelog

=== Source Code changes ===

Document the most important changes but limit verbosity.

* look into the source changelog and pick up the most important changes for the distribution (changes for other operation systems are not important). What has changed in the new version, usually in the level of detail of a NEWS file, the change log files are usually too long. More than '''10-15 lines''' shouldn't be necessary to describe the most important changes.
* arrange the original changes behind the version update information. Example:
- Update to 1.3.2:
+ fixes memory leak in import function
+ new API command: unlock_client()
+ the following bugs are closed by this new upstream release:
++ ............ [MGN:332]
++ .............[MGN:337]
- split of devel package
* If upstream does not provide a meaningful change log, then only do best effort. Don't waste too much time over it.
* If the upstream tarball really has not changed except for the version number, just the version number in the change log would be fine. Same goes for packages just containing some graphics or theming (unless upstream already provides something that fits). If the upstream changes just consists of "updated translation" or "several bug fixes" even that can be sufficient for a changelog entry (unless these bug fixes contain something you find worth mentioning).

== Packaging Static Libraries ==
Packages including libraries should exclude static libs as far as possible (eg by configuring with ''--disable-static''). Static libraries should only be included in exceptional circumstances. Applications linking against libraries should as far as possible link against shared libraries not static versions.

Libtool archives, ''foo.la'' files, should not be included. Packages using libtool will install these by default even if you configure with ''--disable-static'', so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove *.la files without modifying the program. In most cases it is fairly easy to work with upstream to fix these issues. Note that if you are updating a library in a stable release (not devel) and the package already contains *.la files, removing the *.la files should be treated as an API/ABI change -- ie: Removing them changes the interface that the library gives to the rest of the world and should not be undertaken lightly.

=== Packaging Static Libraries ===
* In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists.

* We want to be able to track which packages are using static libraries (so we can find which packages need to be rebuilt if a security flaw in a static library is fixed, for instance). There are two scenarios in which static libraries are packaged:
# '''Static libraries and shared libraries.''' In this case, the static libraries must be placed in a ''*-static'' subpackage. Separating the static libraries from the other development files in ''*-devel'' allow us to track this usage by checking which packages <code>BuildRequire</code> the ''*-static'' package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries.
# '''Static libraries only.''' When a package only provides static libraries you can place all the static library files in the ''*-devel'' subpackage. When doing this you also must have a virtual Provide for the ''*-static'' package:
<pre>%package devel
Provides: foo-static = %{version}-%{release}</pre>

Packages which explicitly need to link against the static version must <code>BuildRequire: foo-static</code>, so that the usage can be tracked.

* If (and only if) a package has shared libraries which require static libraries to be functional, the static libraries can be included in the ''*-devel'' subpackage. The devel subpackage must have a virtual Provide for the ''*-static'' package, and packages dependent on it must <code>BuildRequire</code> the ''*-static'' package.

=== Staticly Linking Executables ===
* Static linkage is a special exception and should be decided on a case-by-case basis. The packager must provide rationale for linking statically, including precedences where available, to release engineering for approval.

[[Category:Packaging]]

Packaging/Guidelines

2010-12-10T12:49:32Z

Mythi: /* Domain/Subsystem based RPM Groups */

= Packaging Guidelines =

Guidelines below were adapted for MeeGo from Moblin, OpenSUSE, Fedora and other distributions.

== Maintaining a Package ==
Every package in MeeGo needs a maintainer (AKA owner, bug owner). Any package without an owner will automatically be nominated for deletion from MeeGo. A package maintainer is responsible for making sure that
* packages are up to date with latest upstream
* packages consistently build in the MeeGo build system and fix build failures when they occur
* package meta data in the RPM spec file is accurate
* the license of the package is correct
* she/he follow upstream for any critical security issues and fix them ASAP
* she/he Provides information about major changes to other packagers and maintainer to allow enough time for fixing compatibility issues

Since the data about ownership of packages is not maintained anywhere right now we are starting to use available meta data fields in the build system to track ownership. This will be better integrated and managed at a later point, but to be able to start somewhere MeeGo will use the bugowner key available for every package. We will start adding the metadata about maintainers (bugowners) in the build system and we will have agrace period for this data to be supplied and added to the build system. After the grace period, packages without maintainer will be reviewed and any packages without a maintainer will be nominated for deletion.

To add yourself as a bugowner of a package, please follow the steps below:
* Update to the most recent osc version (0.129) from the MeeGo tools repository (note: this is essential, since the needed options are not released upstream yet)
* Identify the packages of which you are the ultimate maintainer
* Do the following for every package you maintain in the Trunk:* projects:
<code>
osc reqms --role bugowner <project> <package> -m "I want to own this because I love this package"
</code>
* Your request will be sent and someone in release engineering will approve it

== Package Naming ==
* Dash '-' must be used as the delimiter for name parts.
* Do NOT use an underscore '_', a plus '+', or a period '.' as a delimiter.
* The spec file should be named using the %{name}.spec scheme which should also correspond to the package name within a project in the build system.

== Version and Release ==

Package Versions look like : X.Y.Z-R.B
* X.Y.Z is the 'Version' number - determined by the source package.
* R is the 'Release' number which is automatically incremented by OBS whenever a source/packaging changes (eg a check-in or request acceptance)
* B is the build number which is incremented when the package is rebuilt due to a dependency change.

=== Version ===

The Version field in the spec file is where you should put the current version of the software being packaged.
There are four cases where the version contains non-numeric characters:

* Pre-release packages: Packages released as "pre-release" versions, prior to a "final" version. Example tags include "alpha", "beta", "rc", "cvs", "git", "svn", etc... Details can be found below: Non-Numeric Version.
* Post-release packages: Packages released after a "final" version. These packages contain the same numeric version as the "final" version, but have an additional non-numeric identifier. This mechanism may also be used for packaging only changes to an upstream package.
* Snapshot packages: Packages built from SCM snapshots. These packages could be either "pre" or "post" release packages.

==== Non-Numeric Version ====

We can use letters and tilde into the version tag. We do not use the Release field for this.

Example:
<pre>
Let's assume the following Qt versions:
Qt 4.7.0~beta1
Qt 4.7.0~beta1+git1
Qt 4.7.0~beta2
Qt 4.7.0

Version comparison results:
$ rpmdev-vercmp 4.7.0~beta1 4.7.0~beta1+git1
0:4.7.0~beta1+git1-None is newer

$ rpmdev-vercmp 4.7.0~beta1+git2 4.7.0~beta2
0:4.7.0~beta2-None is newer

$ rpmdev-vercmp 4.7.0~beta2 4.7.0
0:4.7.0-None is newer

Conclusion:
4.7.0~beta1 < 4.7.0~beta1+git1 < 4.7.0~beta2 < 4.7.0
</pre>

Note that the ~ comparison order is specific to MeeGo rpm (http://rpm.org/ticket/56).

=== Release ===

This field is handled by the build system to be able to manage automated builds. The initial setting in the spec file is used by the build system but in many cases it does not need to be changed.

There is no need for the %{dist} macro in the release field. This is also handled directly by the build system.

The release number is set to zero with any version update. It is increased by one with any change in the package.

We can put letters into the version tag, so we do not use the Release field for this. Details can be found above.

If you build the package outside of the OBS or if you copy a package then you will of course not get the correct Release or Build values.

== Tags ==
*The ''Packager'' tag should not be used in spec files. The identities of the packagers are evident from the changelog entries. By not using the ''Packager'' tag, you also avoid seeing bad binaries rebuilt by someone else with your name in the header. See also the '''Maximum RPM definition of the Packager tag''' at [http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html#S3-RPM-INSIDE-PACKAGER-TAG www.rpm.org] . If you need to include information about the packager in the rpms ''you'' built, use <code>%packager</code> in your <code>~/.rpmmacros</code> instead.
*The ''Vendor'' tag should not be used. It is set automatically by the build system.

*Usually, the ''Pre<code></code>Req'' tag should be replaced by plain ''Requires''. For more info, see Maximum RPM snapshot's [http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-FINE-GRAINED fine grained dependencies chapter] .
* The ''Source'' tag documents where to find the upstream sources for the rpm. In most cases this should be a complete URL to the upstream tarball.
=== Summary Tag ===
The summary is a single line string describing the package. The maximum length is 80 characters. It should fit all standard situations and not assume any special context. It should be helpful alone, in alphabetically sorted or unsorted lists of some selected packages, and in alphabetically sorted or unsorted lists of all packages.

It should describe the package's main function and point out any special properties of the package to support the user comparing similar packages. For example, the two words "Web Browser" summarize any web browser, but using additional adjectives (like minimalistic, complex, GNOME, KDE, text-based, fast, or author's) helps characterize a specific package.

The RPM spec file contains only the English version to keep the RPM database small.

*The ''Summary'' tag value should not end in a period. If this bothers you from a grammatical point of view, sit down, take a deep breath, and get over it.

=== Group Tag ===

Valid RPM Groups are:
<pre>
Amusements/Games
Amusements/Graphics
Applications/Archiving
Applications/Communications
Applications/Databases
Applications/Editors
Applications/Emulators
Applications/Engineering
Applications/File
Applications/Internet
Applications/Multimedia
Applications/Productivity
Applications/Publishing
Applications/System
Applications/Text
Development/Debuggers
Development/Languages
Development/Libraries
Development/System
Development/Tools
Documentation
System/Boot
System/Console
System/I18n/Chinese
System/I18n/Japanese
System/I18n/Korean
System/Packages
System/Base
System/Daemons
System/Kernel
System/Libraries
System/Shells
System/X11
System/X11/Fonts
System/X11/Icons
System/GUI/XFCE
System/GUI/Other
System/GUI/GNOME
</pre>

==== Domain/Subsystem based RPM Groups ====

Following the new architecture and the new [http://meego.com/developers/meego-architecture/meego-architecture-domain-view domain view], RPM groups (The Group tag in the RPM) for core packages will be changed to match the domains and any package in the core that is part of one of the domain will have a corresponding group that matches the architecture.

{|
! Domain
! Subsystem
!Groupname
| Communications || Cellular Adaptation || Communications/Cellular Adaptation
|-
| Communications || Cellular Framework || Communications/Cellular Framework
|-
| Communications || Telephony and IM || Communications/Telephony and IM
|-
| Communications || Bluetooth || Connectivity/Bluetooth
|-
| Communications || Connectivity Adaptation || Communications/Connectivity Adaptation
|-
| Communications || ConnMan || Communications/ConnMan
|-
| Data Management || Content Framework || Data Management/Content Framework
|-
| Development Platform || Platform SDK || Development Platform/Platform SDK
|-
| Essentials || Base Essentials || Essentials/Base Essentials
|-
| Graphics || Font Management || Graphics/Font Management
|-
| Graphics || Display and Graphics Adaptation || Graphics/Display and Graphics Adaptation
|-
| Graphics || Input Adaptation || Graphics/Input Adaptation
|-
| Graphics || Open GL ES || Graphics/Open GL ES
|-
| Graphics || X11 || Graphics/X11
|-
| Kernel || Linux Kernel || Kernel/Linux Kernel
|-
| Location || Location Framework || Location/Location Framework
|-
| Location || Location Adaptation || Location/Location Adaptation
|-
| Multimedia || Audio Adaptation || Multimedia/Audio Adaptation
|-
| Multimedia || Camera Adaptation || Multimedia/Camera Adaptation
|-
| Multimedia || Gstreamer || Multimedia/Gstreamer
|-
| Multimedia || Imaging and Video Adaptation || Multimedia/Imaging and Video Adaptation
|-
| Multimedia || Imaging Codecs || Multimedia/Imaging Codecs
|-
| Multimedia || PulseAudio || Multimedia/PulseAudio
|-
| Multimedia || Sharing || Multimedia/Sharing
|-
| Multimedia || UPnP || Multimedia/UPnP
|-
| Personal Information Management || Backup Framework || Personal Information Management/Backup Framework
|-
| Personal Information Management || Calendar Engine || Personal Information Management/Calendar Engine
|-
| Personal Information Management || Contacts Engine || Personal Information Management/Contacts Engine
|-
| Personal Information Management || Email Engine || Personal Information Management/Email Engine
|-
| Personal Information Management || Synchronization Framework || Personal Information Management/Synchronization Framework
|-
| Qt || Qt || Qt/Qt
|-
| Qt || Qt Mobility || Qt/Qt Mobility
|-
| Qt || Qt WebKit || Qt/Qt WebKit
|-
| Qt || Web Runtime || Qt/Web Runtime
|-
| Security || Accounts || Security/Accounts
|-
| Security || Certificate Manager || Security/Certificate Manager
|-
| Security || Integrity Protection Framework || Security/Integrity Protection Framework
|-
| Security || Access Control Framework || Security/Access Control Framework
|-
| Security || Single Sign-On || Security/Single Sign-On
|-
| Security || SW Distribution Security || Security/SW Distribution Security
|-
| Security || Security Adaptation || Security/Security Adaptation
|-
| Software Management || Package Manager || Software Management/Package Manager
|-
| System || Context Framework || System/Context Framework
|-
| System || NGF || System/NGF
|-
| System || Resource Policy || System/Resource Policy
|-
| System || Sensor Adaptation || System/Sensor Adaptation
|-
| System || Sensor Framework || System/Sensor Framework
|-
| System || Startup Services || System/Startup Services
|-
| System || System Control || System/System Control
|-
| System || Device Mode Adaptation || System/Device Mode Adaptation
|-
| System || Vibra and Haptics Adaptation || System/Vibra and Haptics Adaptation
|-

|}

=== BuildRoot tag ===
The ''BuildRoot'' value MUST be below <code>%{_tmppath}/</code> and MUST contain at least <code>%{name}</code>, <code>%{version}</code> and <code>%{release}</code>.

The ''recommended'' values for the ''BuildRoot'' tag are (in descending order of preference) :
<pre>
%{_tmppath}/%{name}-%{version}-%{release}-root
</pre>

The BuildRoot tag can be omitted in packages targeting MeeGo only and is handled directly by rpm in MeeGo, for packages that need to run on other distros with older rpm it should be added for backward compatibility.

=== PreReq ===

Packages should not use the PreReq tag. Once upon a time, in dependency loops PreReq used to "win" over the conventional Requires when RPM determined the installation order in a transaction. This is no longer the case.

=== Explicit Requires ===
Packages must not contain explicit ''Requires'' on libraries except when absolutely
necessary. When explicit library ''Requires'' are necessary, there should be a spec file comment justifying it.

We generally rely on rpmbuild to automatically add dependencies on library SONAMEs.
Modern package management tools are capable of resolving such dependencies to determine
the required packages. Explicit dependencies on specific package names may aid the
inexperienced user, who attempts at installing RPM packages manually, however, history
has shown that such dependencies add confusion when library/files are moved from one
package to another, when packages get renamed, when one out of multiple alternative
packages would suffice, and when versioned explicit dependencies become out-of-date and
inaccurate. Additionally, in some cases, old explicit dependencies on package names
require unnecessary updates/rebuilds.

Exemplary rationale for a versioned explicit dependency:
<pre>
# The automatic dependency on libfubar.so.1 is insufficient,
# as we strictly need at least the release that fixes two segfaults.
Requires: libfubar >= 0:1.2.3-7
</pre>

Packagers should revisit an explicit dependency as appropriate to avoid
it becoming inaccurate and superfluous.

=== BuildRequires ===

In package development and testing, please verify that your package is not missing any necessary build dependencies. Having proper build requirements saves the time of all developers and testers as well as build systems because they will not need to search for missing build requirements manually. It is also a safety feature that prevents builds with that would not otherwise fail, but would be missing crucial features. For example, a graphical application may exclude PNG support after its '''configure''' script detects that libpng is not installed.

Before adding Build<code></code>Requires to any package, please be comfortable with [[#Requires| Requires]] .

=== Patches ===
Each problem should be solved in a separate patch. To allow easy maintenance of patches, every patch should have a header providing the following information:

* Authors' names
* [http://meego.com/about/contribution-guidelines/signed-process Signed-off-by] tag
* Detailed description of the fixed problem
* URL of the original source of the patch if any

The name of a patch file consists of:

* The name and version of the source tarball from which the patched file is derived
* Some words that characterize the patch content
* The filename suffix <code class="filename">.patch</code>

Patches are in the unified format ('''diff -u''') and should be applied with 1 strip level in the spec file ('''%patch -p1'''). The only exceptions are the patches obtained from an another primary source site. The original name, suffix, and format is preserved in this case.

Each patch should be compressed with '''bzip2''' if its size is greater than 100kB. The macros <code class="systemitem">%name</code> and <code class="systemitem">%version</code> should be used whenever possible.

Example:

Source: %{name}-%{version}.tar.bz2
Patch0: %{name}-%{version}-autoconf.patch
Patch1: %{name}-%{version}-gcc31.patch

For the patches to be applied, the patches should be mentioned under %setup. For the above example, this could be done as

%setup -q
%patch0 -p1
%patch1 -p1

Patches have to be marked as such in the spec file and should be applied using the internal patch routines available in rpm. Use of alternate patch management system not supported by rpm is not allowed.

=== %clean ===

The %clean section is not required for MeeGo 1.1 and above. Each package for MeeGo 1.0 MUST have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).

== Documentation ==
Any relevant documentation included in the source distribution should be included in the package. Irrelevant documentation include build instructions, the omnipresent ''INSTALL'' file containing generic build instructions, for example, and documentation for non-Linux systems, e.g. ''README.MSDOS''. Pay also attention about which subpackage you include documentation in, for example API documentation belongs in the -devel subpackage, not the main one. Or if there's a lot of documentation, consider putting it into a subpackage. In this case, it is recommended to use <code>*-doc</code> as the subpackage name, and <code>Documentation</code> as the value of the <code>Group</code> tag.

Also, if a package includes something as <code>%doc</code>, it must not affect the runtime of the application. To summarize: If it is in <code>%doc</code>, the program must run properly if it is not present.

== Devel Packages ==
If the software being packaged contains files intended solely for development, those files should be put in a -devel subpackage. The following are examples of file types which should be in -devel:
* Header files (such as .h files)
* Unversioned shared libraries (such as libfoo.so). Versioned shared libraries (such as libfoo.so.3, libfoo.so.3.0.0) should not be in -devel.

A good rule of thumb is if the file is used for development and not needed for the base package to run properly, it should go in -devel.

=== Requiring Base Package ===
Devel packages must require the base package using a fully versioned dependency: <code>Requires: %{name} = %{version}-%{release}</code>.
Usually, subpackages other than -devel should also require the base package using a fully versioned dependency.

=== Pkgconfig Files ===
The placement of pkgconfig(.pc) files depends on their usecase. Since they are almost always used for development purposes, they should be placed in a -devel package.
A reasonable exception is when the main package itself is a development tool not installed in a user runtime, such as gcc or gdb.

== Test Packages ==
Tests should be included in -test subpackage or separate package according to the following guidelines.

[http://wiki.meego.com/Test_Packaging Test Packaging Guidelines]

== Shared Libraries ==
Whenever possible (and feasible), MeeGo Packages containing libraries should build them as shared libraries. In addition, every binary RPM package which contains shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in <code>%post</code> and <code>%postun</code>. If the package has multiple subpackages with libraries, each subpackage should also have a <code>%post/%postun</code> section that calls <code>/sbin/ldconfig</code>. An example of the correct syntax for this is:
<pre>
%post -p /sbin/ldconfig

%postun -p /sbin/ldconfig
</pre>
Note that this specific syntax only works if <code>/sbin/ldconfig</code> is the only call in <code>%post</code> and <code>%postun</code>. If you have additional commands to run during the scriptlet, call <code>/sbin/ldconfig</code> at the beginning of the scriptlet, like this:
<pre>
%post
/sbin/ldconfig
/usr/bin/foo --add

%postun
/sbin/ldconfig
/usr/bin/foo --remove
</pre>

== Configuration files ==

Configuration files must be marked as such in packages.

As a rule of thumb, use <code>%config(noreplace)</code> instead of plain <code>%config</code> unless your best, educated guess is that doing so will break things. In other words, think hard before overwriting local changes in configuration files on package upgrades. An example case when /not/ to use <code>noreplace</code> is when a package's configuration file changes so that the new package revision wouldn't work with the config file from the previous package revision. Whenever plain <code>%config</code> is used, add a brief comment to the specfile explaining why.

Don't use %config or %config(noreplace) under /usr. /usr is deemed to not contain configuration files in MeeGo.

== Initscripts ==

Currently, only SystemV-style initscripts are supported in MeeGo.

== Desktop files ==

If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window. Installed .desktop files MUST follow the [http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html desktop-entry-spec] , paying particular attention to validating correct usage of Name, GenericName, [http://standards.freedesktop.org/menu-spec/latest/apa.html Categories] ,
[http://www.freedesktop.org/Standards/startup-notification-spec StartupNotify]
entries.

=== Icon tag in Desktop Files ===
The icon tag can be specified in two ways:

* Full path to specific icon file:
<code> Icon=/usr/share/pixmaps/comical.png </code>

* Short name without file extension:
<code> Icon=comical </code>

The short name without file extension is preferred, because it allows for icon theming (it assumes .png by default, then tries .svg and finally .xpm), but either method is acceptable.

=== .desktop file creation ===
If the package doesn't already include and install its own .desktop file, you need to make your own. You can do this by including a .desktop file you create as a Source: (such as Source3: %{name}.desktop) or generating it in the spec file. Here are the contents of a sample .desktop file (comical.desktop):

<pre>
[Desktop Entry]
Name=Comical
GenericName=Comic Archive Reader
Comment=Open .cbr & .cbz files
Exec=comical
Icon=comical
Terminal=false
Type=Application
Categories=Graphics;
</pre>

=== desktop-file-install usage ===
It is not simply enough to just include the .desktop file in the package, one MUST run <code>desktop-file-install</code> OR <code>desktop-file-validate</code> in <code>%install</code> (and have <code>BuildRequires: desktop-file-utils</code>), to help ensure .desktop file safety and spec-compliance. <code>desktop-file-install</code> MUST be used if the package does not install the file or there are changes desired to the .desktop file (such as add/removing categories, etc). <code>desktop-file-validate</code> MAY be used instead if the .desktop file's content/location does not need modification. Here are some examples of
usage:

<pre>
desktop-file-install \
--dir=${RPM_BUILD_ROOT}%{_datadir}/applications \
%{SOURCE3}
</pre>

<pre>
desktop-file-install \
--add-category="AudioVideo" \
--delete-original \
--dir=%{buildroot}%{_datadir}/applications \
%{buildroot}/%{_datadir}/foo.desktop
</pre>

<pre>
desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop
</pre>

== Macros ==
=== Using %{buildroot} and %{optflags} vs $RPM_BUILD_ROOT and $RPM_OPT_FLAGS ===
There are two styles of defining the rpm Build Root and Optimization Flags in a spec file:

{| border="1"
|-
| ||macro style || variable style
|-
|Build Root||%{buildroot}||$RPM_BUILD_ROOT
|-
|Opt. Flags||%{optflags}||$RPM_OPT_FLAGS
|}

There is very little value in choosing one style over the other, since they will resolve to the same values in all scenarios. You should pick a style and use it consistently throughout your packaging.

Mixing the two styles, while valid, is bad from a QA and usability point of view, and should not be done in MeeGo packages.

== Handling Locale Files ==

If the package includes translations, add
<pre>
BuildRequires: gettext
</pre>
If you don't, your package could fail to generate translation files in the buildroot.

MeeGo includes an rpm macro called <code>%find_lang</code>. This macro will locate all of the locale files that belong to your package (by name), and put this list in a file. You can then use that file to include all of the locales. <code>%find_lang</code> should be run in the %install section of your spec file, after all of the files have been installed into the buildroot. The correct syntax for <code>%find_lang</code> is usually:
<pre>
%find_lang %{name}
</pre>
In some cases, the application may use a different "name" for its locales. You may have to look at the locale files and see what they are named. If they are named <code>myapp.mo</code>, then you will need to pass <code>myapp</code> to <code>%find_lang</code> instead of <code>%{name</code>}.
After <code>%find_lang</code> is run, it will generate a file in the active directory (by default, the top level of the source dir). This file will be named based on what you passed as the option to the <code>%find_lang</code> macro. Usually, it will be named <code>%{name}.lang</code>. You should then use this file in the <code>%files</code> list to include the locales detected by <code>%find_lang</code>. To do this, you should include it with the -f parameter to <code>%files</code>.
<pre>
%files -f %{name}.lang
%defattr(-,root,root,-)
%{_bindir}/foobar
...
</pre>
If you are already using the -f parameter for the <code>%files</code> section where the locales should live, just append the contents of <code>%{name}.lang</code> to the end of the file that you are already using with -f. (Note that only one file may be used with <code>%files -f</code>.)

Here is an example of proper usage of <code>%find_lang</code>, in <code>foo.spec</code>:

<pre>
...
%prep
%setup -q

%build
%configure --with-cheese
make %{?_smp_mflags}

%install
make DESTDIR=%{buildroot} install
%find_lang %{name}

%clean
rm -rf %{buildroot}

%files -f %{name}.lang
%defattr(-,root,root,-)
%doc LICENSE README
%{_bindir}/foobar

</pre>

=== Why do we need to use %find_lang? ===

Using <code>%find_lang</code> helps keep the spec file simple, and helps avoid several other packaging mistakes.

* Packages that use <code>%{_datadir}/*</code> to grab all the locale files in one line also grab ownership of the locale directories, which is not permitted.
* Most packages that have locales have lots of locales. Using <code>%find_lang</code> is much easier in the spec file than having to do:
<pre>
%{_datadir}/locale/ar/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/be/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/cs/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/de/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/es/LC_MESSAGES/%{name}.mo
...
</pre>
* As new locale files appear in later package revisions, <code>%find_lang</code> will automatically include them when it is run, preventing you from having to update the spec any more than is necessary.

Keep in mind that usage of <code>%find_lang</code> in packages containing locales is a MUST.

== Scriptlets ==
Great care should be taken when using scriptlets in MeeGo packages. If scriptlets are used, those scriptlets must be sane.

=== Scriptlets requirements ===
Do not use the <code>Requires(pre,post)</code> style notation for scriptlet dependencies, because of two bugs in RPM. Instead, they should be split like this:
<pre>
Requires(pre): ...
Requires(post): ...
</pre>
For more information, see [http://www.redhat.com/archives/fedora-devel-list/2004-April/msg00674.html www.redhat.com] .

=== Running scriptlets only in certain situations ===
When the rpm command executes the scriptlets in a package it indicates if the action preformed is an install, erase, upgrade or reinstall by passing an integer argument to the script in question according to the following:
<pre>
install erase upgrade reinstall
%pre 1 - 2 2
%post 1 - 2 2
%preun - 0 1 -
%postun - 0 1 -
</pre>
This means that for example a package that installs an init script with the <code>chkconfig</code> command should uninstall it only on erase and not upgrade with the following snippet:
<pre>
%preun
if [ $1 -eq 0 ] ; then
/sbin/chkconfig --del %{name}
fi
</pre>
See also <code>/usr/share/doc/rpm-*/triggers</code>, which gives a more formal, generalized definition about the integer value(s) passed to various scripts.

=== Scriplets are only allowed to write in certain directories ===
Build scripts of packages (%prep, %build, %install, %check and %clean) may only alter files (create, modify, delete) under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process) according to the following matrix

{| border="1"
|-
| || /tmp, /var/tmp, $TMPDIR, %{_tmppath} || %{_builddir} || %{buildroot}
|-
|%prep || yes || yes || no
|-
|%build || yes || yes || no
|-
|%install || yes || yes || yes
|-
|%check || yes || yes || no
|-
|%clean || yes || yes || yes
|}

Further clarification: That should hold true irrespective of the builder's uid.

== Use of Epochs ==
The Epoch tag in RPM is to be used only as a last resort, and should be avoided whenever possible. However, it is sometimes necessary to use an Epoch to handle upstream versioning changes or to ease transition from third party repositories.

== Writing a package from scratch ==

See [[Spectacle]]

Spectacle is a great tool for straightforward packages, and we have many of those, hundreds, many of those packages already have been using spectacle happily for a while now. Generally, the 80/20 rule applies here, almost 80% of packages in MeeGo can be converted to this format, probably around 20% will need to stay as is for various reasons.

Spectacle in general helps a lot when you have a package that does:
* configure
* make
* make install

and especially useful when for example you have to manage many build dependencies and patches or for common packaging of perl/python/X packages that usually follows the same packaging work flow. We have plans to add lots of nice features to make packaging easier and more fun with spectacle.

While spectacle has many advanced options to cover all kind of corner cases, it should not be used for complex packages that would require lots of customization, especially now that we support multiple architectures and where we need to apply code and custom scripts to support different scenarios.

Spectacle provides scripts to convert spec files to spectacle, those try to do their best but you SHOULD never just take the output as is and rely on the script, a review of the output is necessary, otherwise you might end up with lots of duplication in the spec file. This is the most common mistake, developers are relying on the output of the conversion script, basically picking some spec file from another distro and converting it. This can lead to major disasters in some cases.

So to summarize:
* It is NOT mandatory to use spectacle
* If you try to convert and find yourself spending more than a few minutes on a package, then probably there is something wrong and you should not be using that or you should RTFM.
* Use it with care, especially when you first import the data from existing spec files or when you first create your YAML file
* Your distro maintainer might send you a note that certain packages you are maintaining could be converted to spectacle easily, but she/he should not reject your package because it does not use spectacle.
* If you find yourself forced to edit the spec file manually for some reason, then either:
** your package is not suitable to be used with spectacle
** or you might want to ask for a feature to support that special case

== Modifying existing Packages ==

If you base a new package on an existing non-MeeGo package, make sure you verify its correctness of the package and the spec file and to understand exactly what has been done to package the software exactly. Do not submit a package without knowing what those strange, but innocent-looking commands do.

In particular, you should

* ensure that original tarballs are self-contained pristine tarballs. The tarball should not contain symlinks that reference outside the tarball root directory
* verify any sources and patches and remove patches or sources that:
** are related to platforms we do not support (example: sparc, ia64, ppc, ...)
** Implement features we do not support (example: selinux)
** Read every patch and understand what it does, if it is needed, put an explanation in the header justifying why the patch is needed.
* verify that the license stated in the spec file matches the actual license of the software,
* skim the summary and description for typos and oddities (see Summary and description ),
* make sure that the correct build root is used,
* ensure that macro usage is consistent and that the macros are available in MeeGo (see Macros ).

Keep old changelog entries to credit the original authors. Entries that are several years old or refer to ancient versions of the software may be erased. If you end up doing radical changes and re-write most of the spec file anyway, feel free to start the changelog from scratch. In other words, use your best judgement.

== Changelogs ==

This section describes the MeeGo policy for RPM changelogs. (Original changelogs included in the original source are not affected by this policy.)

Please consider that a "normal end user with some technical skills" should be able to read and understand an RPM changelog. Changelog entries have to be in reverse chronological order: newer change log entries are listed above older entries, with the first entry being the most recent.

Please bear in mind theat MeeGo changelogs will be automatically parsed to prepare distribution release notes and to report on bugs and CVEs and malformed entries may not be read correctly.

=== General information ===

* MeeGo uses a separate file for package changes which is similar to a debian changelog file. This file is named as the spec file, but ends in *.changes instead of *.spec
* Entries in the changes file should have the following structure:
<pre>
* dow mmm dd yyyy Name Goes Here <your@email.com> - [version]
- comment
- comment

</pre>

Note the following exceptions are noted through observation:
* version is often omitted (such as: alsa-utils 1.0.15-1 -> 1.0.16-1)
* there are multiple changelog entries per version (such as: alsa-utils 1.0.19)
* the hyphen between email and version is often omitted (such as: alsa-utils)
* spaces between name and <email> are omitted (such as: Zhang, Qiang Z<qiang.z.zhang@intel.com> nano)
* name is sometimes omitted (such as: bitstream-vera-fonts nicolas.mailhot at laposte.net)
* <email> is sometimes omitted (such as: binutils Jim Kingdon)
This wide variation in formats makes automation tasks harder than they should be. Please use the correct format.

=== External References ===

Each external reference (bug numbers etc) should be of the form:
"(" + external reference code + bug number +")"

Currently defined:
* MeeGo Bugs : BMC#
* MeeGo Features: FEA#
* Common Vulnerability / Exposure : CVE

==== Bug Numbers in the change log ====

During maintenance of a distribution, every change has to be marked with the correct bug number. Normally this has to be an number from https://bugzilla.meego.com/. Add an entry with bugzilla number and a short description of the bug-summary. For example:
- Removed invalid desktop Category "Application" (BMC#4654).
- Symlink icon to pixmaps dir (BMC#2108)
- Added gnome-ui-properties to control-center (BMC#1960).

New packages related to new features will refer to the corresponding bug number in bugzilla, preceded with an FEA. For example:
- Adding Qt Contacts support FEA#8011

==== CVE numbers in change log ====

As with bug numbers: Add a short description (normally the CVE summary should be enough), the Bugzilla and the CVE number to the changelog entry. Examples:
- Add gdk-pixbuf-226710.patch (BMC#226710), and (CVE-2007-0010).
- More XPM fixes: (CVE-2005-2975) xpm too many colors DoS (BMC#129642)
- fix ~/.dmrc symlink attack (BMC#180704), (CVE-2006-2449)

=== Spec File changes ===
Be as precise as possible! This is especially important if you remove something from the spec file.

* Removing original source code must be declared in spec file with a comment ("useful for FreeBSD only" for example) - not necessary to repeat the comment in specfile.
* Extra commands (for example during %install) can be illustrated with a short comment in spec file
* Adding/Removing packages from Requires/Provides must be described in the changelog

=== Source Code changes ===

Document the most important changes but limit verbosity.

* look into the source changelog and pick up the most important changes for the distribution (changes for other operation systems are not important). What has changed in the new version, usually in the level of detail of a NEWS file, the change log files are usually too long. More than '''10-15 lines''' shouldn't be necessary to describe the most important changes.
* arrange the original changes behind the version update information. Example:
- Update to 1.3.2:
+ fixes memory leak in import function
+ new API command: unlock_client()
+ the following bugs are closed by this new upstream release:
++ ............ [MGN:332]
++ .............[MGN:337]
- split of devel package
* If upstream does not provide a meaningful change log, then only do best effort. Don't waste too much time over it.
* If the upstream tarball really has not changed except for the version number, just the version number in the change log would be fine. Same goes for packages just containing some graphics or theming (unless upstream already provides something that fits). If the upstream changes just consists of "updated translation" or "several bug fixes" even that can be sufficient for a changelog entry (unless these bug fixes contain something you find worth mentioning).

== Packaging Static Libraries ==
Packages including libraries should exclude static libs as far as possible (eg by configuring with ''--disable-static''). Static libraries should only be included in exceptional circumstances. Applications linking against libraries should as far as possible link against shared libraries not static versions.

Libtool archives, ''foo.la'' files, should not be included. Packages using libtool will install these by default even if you configure with ''--disable-static'', so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove *.la files without modifying the program. In most cases it is fairly easy to work with upstream to fix these issues. Note that if you are updating a library in a stable release (not devel) and the package already contains *.la files, removing the *.la files should be treated as an API/ABI change -- ie: Removing them changes the interface that the library gives to the rest of the world and should not be undertaken lightly.

=== Packaging Static Libraries ===
* In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists.

* We want to be able to track which packages are using static libraries (so we can find which packages need to be rebuilt if a security flaw in a static library is fixed, for instance). There are two scenarios in which static libraries are packaged:
# '''Static libraries and shared libraries.''' In this case, the static libraries must be placed in a ''*-static'' subpackage. Separating the static libraries from the other development files in ''*-devel'' allow us to track this usage by checking which packages <code>BuildRequire</code> the ''*-static'' package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries.
# '''Static libraries only.''' When a package only provides static libraries you can place all the static library files in the ''*-devel'' subpackage. When doing this you also must have a virtual Provide for the ''*-static'' package:
<pre>%package devel
Provides: foo-static = %{version}-%{release}</pre>

Packages which explicitly need to link against the static version must <code>BuildRequire: foo-static</code>, so that the usage can be tracked.

* If (and only if) a package has shared libraries which require static libraries to be functional, the static libraries can be included in the ''*-devel'' subpackage. The devel subpackage must have a virtual Provide for the ''*-static'' package, and packages dependent on it must <code>BuildRequire</code> the ''*-static'' package.

=== Staticly Linking Executables ===
* Static linkage is a special exception and should be decided on a case-by-case basis. The packager must provide rationale for linking statically, including precedences where available, to release engineering for approval.

[[Category:Packaging]]

Packaging/Guidelines

2010-12-10T12:48:27Z

Mythi: Remove AF subsystems, rename connectivity -> communications

= Packaging Guidelines =

Guidelines below were adapted for MeeGo from Moblin, OpenSUSE, Fedora and other distributions.

== Maintaining a Package ==
Every package in MeeGo needs a maintainer (AKA owner, bug owner). Any package without an owner will automatically be nominated for deletion from MeeGo. A package maintainer is responsible for making sure that
* packages are up to date with latest upstream
* packages consistently build in the MeeGo build system and fix build failures when they occur
* package meta data in the RPM spec file is accurate
* the license of the package is correct
* she/he follow upstream for any critical security issues and fix them ASAP
* she/he Provides information about major changes to other packagers and maintainer to allow enough time for fixing compatibility issues

Since the data about ownership of packages is not maintained anywhere right now we are starting to use available meta data fields in the build system to track ownership. This will be better integrated and managed at a later point, but to be able to start somewhere MeeGo will use the bugowner key available for every package. We will start adding the metadata about maintainers (bugowners) in the build system and we will have agrace period for this data to be supplied and added to the build system. After the grace period, packages without maintainer will be reviewed and any packages without a maintainer will be nominated for deletion.

To add yourself as a bugowner of a package, please follow the steps below:
* Update to the most recent osc version (0.129) from the MeeGo tools repository (note: this is essential, since the needed options are not released upstream yet)
* Identify the packages of which you are the ultimate maintainer
* Do the following for every package you maintain in the Trunk:* projects:
<code>
osc reqms --role bugowner <project> <package> -m "I want to own this because I love this package"
</code>
* Your request will be sent and someone in release engineering will approve it

== Package Naming ==
* Dash '-' must be used as the delimiter for name parts.
* Do NOT use an underscore '_', a plus '+', or a period '.' as a delimiter.
* The spec file should be named using the %{name}.spec scheme which should also correspond to the package name within a project in the build system.

== Version and Release ==

Package Versions look like : X.Y.Z-R.B
* X.Y.Z is the 'Version' number - determined by the source package.
* R is the 'Release' number which is automatically incremented by OBS whenever a source/packaging changes (eg a check-in or request acceptance)
* B is the build number which is incremented when the package is rebuilt due to a dependency change.

=== Version ===

The Version field in the spec file is where you should put the current version of the software being packaged.
There are four cases where the version contains non-numeric characters:

* Pre-release packages: Packages released as "pre-release" versions, prior to a "final" version. Example tags include "alpha", "beta", "rc", "cvs", "git", "svn", etc... Details can be found below: Non-Numeric Version.
* Post-release packages: Packages released after a "final" version. These packages contain the same numeric version as the "final" version, but have an additional non-numeric identifier. This mechanism may also be used for packaging only changes to an upstream package.
* Snapshot packages: Packages built from SCM snapshots. These packages could be either "pre" or "post" release packages.

==== Non-Numeric Version ====

We can use letters and tilde into the version tag. We do not use the Release field for this.

Example:
<pre>
Let's assume the following Qt versions:
Qt 4.7.0~beta1
Qt 4.7.0~beta1+git1
Qt 4.7.0~beta2
Qt 4.7.0

Version comparison results:
$ rpmdev-vercmp 4.7.0~beta1 4.7.0~beta1+git1
0:4.7.0~beta1+git1-None is newer

$ rpmdev-vercmp 4.7.0~beta1+git2 4.7.0~beta2
0:4.7.0~beta2-None is newer

$ rpmdev-vercmp 4.7.0~beta2 4.7.0
0:4.7.0-None is newer

Conclusion:
4.7.0~beta1 < 4.7.0~beta1+git1 < 4.7.0~beta2 < 4.7.0
</pre>

Note that the ~ comparison order is specific to MeeGo rpm (http://rpm.org/ticket/56).

=== Release ===

This field is handled by the build system to be able to manage automated builds. The initial setting in the spec file is used by the build system but in many cases it does not need to be changed.

There is no need for the %{dist} macro in the release field. This is also handled directly by the build system.

The release number is set to zero with any version update. It is increased by one with any change in the package.

We can put letters into the version tag, so we do not use the Release field for this. Details can be found above.

If you build the package outside of the OBS or if you copy a package then you will of course not get the correct Release or Build values.

== Tags ==
*The ''Packager'' tag should not be used in spec files. The identities of the packagers are evident from the changelog entries. By not using the ''Packager'' tag, you also avoid seeing bad binaries rebuilt by someone else with your name in the header. See also the '''Maximum RPM definition of the Packager tag''' at [http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html#S3-RPM-INSIDE-PACKAGER-TAG www.rpm.org] . If you need to include information about the packager in the rpms ''you'' built, use <code>%packager</code> in your <code>~/.rpmmacros</code> instead.
*The ''Vendor'' tag should not be used. It is set automatically by the build system.

*Usually, the ''Pre<code></code>Req'' tag should be replaced by plain ''Requires''. For more info, see Maximum RPM snapshot's [http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-FINE-GRAINED fine grained dependencies chapter] .
* The ''Source'' tag documents where to find the upstream sources for the rpm. In most cases this should be a complete URL to the upstream tarball.
=== Summary Tag ===
The summary is a single line string describing the package. The maximum length is 80 characters. It should fit all standard situations and not assume any special context. It should be helpful alone, in alphabetically sorted or unsorted lists of some selected packages, and in alphabetically sorted or unsorted lists of all packages.

It should describe the package's main function and point out any special properties of the package to support the user comparing similar packages. For example, the two words "Web Browser" summarize any web browser, but using additional adjectives (like minimalistic, complex, GNOME, KDE, text-based, fast, or author's) helps characterize a specific package.

The RPM spec file contains only the English version to keep the RPM database small.

*The ''Summary'' tag value should not end in a period. If this bothers you from a grammatical point of view, sit down, take a deep breath, and get over it.

=== Group Tag ===

Valid RPM Groups are:
<pre>
Amusements/Games
Amusements/Graphics
Applications/Archiving
Applications/Communications
Applications/Databases
Applications/Editors
Applications/Emulators
Applications/Engineering
Applications/File
Applications/Internet
Applications/Multimedia
Applications/Productivity
Applications/Publishing
Applications/System
Applications/Text
Development/Debuggers
Development/Languages
Development/Libraries
Development/System
Development/Tools
Documentation
System/Boot
System/Console
System/I18n/Chinese
System/I18n/Japanese
System/I18n/Korean
System/Packages
System/Base
System/Daemons
System/Kernel
System/Libraries
System/Shells
System/X11
System/X11/Fonts
System/X11/Icons
System/GUI/XFCE
System/GUI/Other
System/GUI/GNOME
</pre>

==== Domain/Subsystem based RPM Groups ====

Following the new architecture and the new [http://meego.com/developers/meego-architecture/meego-architecture-domain-view domain view], RPM groups (The Group tag in the RPM) for core packages will be changed to match the domains and any package in the core that is part of one of the domain will have a corresponding group that matches the architecture.

{|
! Domain
! Subsystem
!Groupname
| Communications || Cellular Adaptation || Communications/Cellular Adaptation
|-
| Communications || Cellular Framework || Communications/Cellular Framework
|-
| Communications || Telephony and IM || Communications/Telephony and IM
|-
| Communications || Bluetooth || Connectivity/Bluetooth
|-
| Communications || Connectivity Adaptation || Connectivity/Connectivity Adaptation
|-
| Communications || ConnMan || Connectivity/ConnMan
|-
| Data Management || Content Framework || Data Management/Content Framework
|-
| Development Platform || Platform SDK || Development Platform/Platform SDK
|-
| Essentials || Base Essentials || Essentials/Base Essentials
|-
| Graphics || Font Management || Graphics/Font Management
|-
| Graphics || Display and Graphics Adaptation || Graphics/Display and Graphics Adaptation
|-
| Graphics || Input Adaptation || Graphics/Input Adaptation
|-
| Graphics || Open GL ES || Graphics/Open GL ES
|-
| Graphics || X11 || Graphics/X11
|-
| Kernel || Linux Kernel || Kernel/Linux Kernel
|-
| Location || Location Framework || Location/Location Framework
|-
| Location || Location Adaptation || Location/Location Adaptation
|-
| Multimedia || Audio Adaptation || Multimedia/Audio Adaptation
|-
| Multimedia || Camera Adaptation || Multimedia/Camera Adaptation
|-
| Multimedia || Gstreamer || Multimedia/Gstreamer
|-
| Multimedia || Imaging and Video Adaptation || Multimedia/Imaging and Video Adaptation
|-
| Multimedia || Imaging Codecs || Multimedia/Imaging Codecs
|-
| Multimedia || PulseAudio || Multimedia/PulseAudio
|-
| Multimedia || Sharing || Multimedia/Sharing
|-
| Multimedia || UPnP || Multimedia/UPnP
|-
| Personal Information Management || Backup Framework || Personal Information Management/Backup Framework
|-
| Personal Information Management || Calendar Engine || Personal Information Management/Calendar Engine
|-
| Personal Information Management || Contacts Engine || Personal Information Management/Contacts Engine
|-
| Personal Information Management || Email Engine || Personal Information Management/Email Engine
|-
| Personal Information Management || Synchronization Framework || Personal Information Management/Synchronization Framework
|-
| Qt || Qt || Qt/Qt
|-
| Qt || Qt Mobility || Qt/Qt Mobility
|-
| Qt || Qt WebKit || Qt/Qt WebKit
|-
| Qt || Web Runtime || Qt/Web Runtime
|-
| Security || Accounts || Security/Accounts
|-
| Security || Certificate Manager || Security/Certificate Manager
|-
| Security || Integrity Protection Framework || Security/Integrity Protection Framework
|-
| Security || Access Control Framework || Security/Access Control Framework
|-
| Security || Single Sign-On || Security/Single Sign-On
|-
| Security || SW Distribution Security || Security/SW Distribution Security
|-
| Security || Security Adaptation || Security/Security Adaptation
|-
| Software Management || Package Manager || Software Management/Package Manager
|-
| System || Context Framework || System/Context Framework
|-
| System || NGF || System/NGF
|-
| System || Resource Policy || System/Resource Policy
|-
| System || Sensor Adaptation || System/Sensor Adaptation
|-
| System || Sensor Framework || System/Sensor Framework
|-
| System || Startup Services || System/Startup Services
|-
| System || System Control || System/System Control
|-
| System || Device Mode Adaptation || System/Device Mode Adaptation
|-
| System || Vibra and Haptics Adaptation || System/Vibra and Haptics Adaptation
|-

|}

=== BuildRoot tag ===
The ''BuildRoot'' value MUST be below <code>%{_tmppath}/</code> and MUST contain at least <code>%{name}</code>, <code>%{version}</code> and <code>%{release}</code>.

The ''recommended'' values for the ''BuildRoot'' tag are (in descending order of preference) :
<pre>
%{_tmppath}/%{name}-%{version}-%{release}-root
</pre>

The BuildRoot tag can be omitted in packages targeting MeeGo only and is handled directly by rpm in MeeGo, for packages that need to run on other distros with older rpm it should be added for backward compatibility.

=== PreReq ===

Packages should not use the PreReq tag. Once upon a time, in dependency loops PreReq used to "win" over the conventional Requires when RPM determined the installation order in a transaction. This is no longer the case.

=== Explicit Requires ===
Packages must not contain explicit ''Requires'' on libraries except when absolutely
necessary. When explicit library ''Requires'' are necessary, there should be a spec file comment justifying it.

We generally rely on rpmbuild to automatically add dependencies on library SONAMEs.
Modern package management tools are capable of resolving such dependencies to determine
the required packages. Explicit dependencies on specific package names may aid the
inexperienced user, who attempts at installing RPM packages manually, however, history
has shown that such dependencies add confusion when library/files are moved from one
package to another, when packages get renamed, when one out of multiple alternative
packages would suffice, and when versioned explicit dependencies become out-of-date and
inaccurate. Additionally, in some cases, old explicit dependencies on package names
require unnecessary updates/rebuilds.

Exemplary rationale for a versioned explicit dependency:
<pre>
# The automatic dependency on libfubar.so.1 is insufficient,
# as we strictly need at least the release that fixes two segfaults.
Requires: libfubar >= 0:1.2.3-7
</pre>

Packagers should revisit an explicit dependency as appropriate to avoid
it becoming inaccurate and superfluous.

=== BuildRequires ===

In package development and testing, please verify that your package is not missing any necessary build dependencies. Having proper build requirements saves the time of all developers and testers as well as build systems because they will not need to search for missing build requirements manually. It is also a safety feature that prevents builds with that would not otherwise fail, but would be missing crucial features. For example, a graphical application may exclude PNG support after its '''configure''' script detects that libpng is not installed.

Before adding Build<code></code>Requires to any package, please be comfortable with [[#Requires| Requires]] .

=== Patches ===
Each problem should be solved in a separate patch. To allow easy maintenance of patches, every patch should have a header providing the following information:

* Authors' names
* [http://meego.com/about/contribution-guidelines/signed-process Signed-off-by] tag
* Detailed description of the fixed problem
* URL of the original source of the patch if any

The name of a patch file consists of:

* The name and version of the source tarball from which the patched file is derived
* Some words that characterize the patch content
* The filename suffix <code class="filename">.patch</code>

Patches are in the unified format ('''diff -u''') and should be applied with 1 strip level in the spec file ('''%patch -p1'''). The only exceptions are the patches obtained from an another primary source site. The original name, suffix, and format is preserved in this case.

Each patch should be compressed with '''bzip2''' if its size is greater than 100kB. The macros <code class="systemitem">%name</code> and <code class="systemitem">%version</code> should be used whenever possible.

Example:

Source: %{name}-%{version}.tar.bz2
Patch0: %{name}-%{version}-autoconf.patch
Patch1: %{name}-%{version}-gcc31.patch

For the patches to be applied, the patches should be mentioned under %setup. For the above example, this could be done as

%setup -q
%patch0 -p1
%patch1 -p1

Patches have to be marked as such in the spec file and should be applied using the internal patch routines available in rpm. Use of alternate patch management system not supported by rpm is not allowed.

=== %clean ===

The %clean section is not required for MeeGo 1.1 and above. Each package for MeeGo 1.0 MUST have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).

== Documentation ==
Any relevant documentation included in the source distribution should be included in the package. Irrelevant documentation include build instructions, the omnipresent ''INSTALL'' file containing generic build instructions, for example, and documentation for non-Linux systems, e.g. ''README.MSDOS''. Pay also attention about which subpackage you include documentation in, for example API documentation belongs in the -devel subpackage, not the main one. Or if there's a lot of documentation, consider putting it into a subpackage. In this case, it is recommended to use <code>*-doc</code> as the subpackage name, and <code>Documentation</code> as the value of the <code>Group</code> tag.

Also, if a package includes something as <code>%doc</code>, it must not affect the runtime of the application. To summarize: If it is in <code>%doc</code>, the program must run properly if it is not present.

== Devel Packages ==
If the software being packaged contains files intended solely for development, those files should be put in a -devel subpackage. The following are examples of file types which should be in -devel:
* Header files (such as .h files)
* Unversioned shared libraries (such as libfoo.so). Versioned shared libraries (such as libfoo.so.3, libfoo.so.3.0.0) should not be in -devel.

A good rule of thumb is if the file is used for development and not needed for the base package to run properly, it should go in -devel.

=== Requiring Base Package ===
Devel packages must require the base package using a fully versioned dependency: <code>Requires: %{name} = %{version}-%{release}</code>.
Usually, subpackages other than -devel should also require the base package using a fully versioned dependency.

=== Pkgconfig Files ===
The placement of pkgconfig(.pc) files depends on their usecase. Since they are almost always used for development purposes, they should be placed in a -devel package.
A reasonable exception is when the main package itself is a development tool not installed in a user runtime, such as gcc or gdb.

== Test Packages ==
Tests should be included in -test subpackage or separate package according to the following guidelines.

[http://wiki.meego.com/Test_Packaging Test Packaging Guidelines]

== Shared Libraries ==
Whenever possible (and feasible), MeeGo Packages containing libraries should build them as shared libraries. In addition, every binary RPM package which contains shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in <code>%post</code> and <code>%postun</code>. If the package has multiple subpackages with libraries, each subpackage should also have a <code>%post/%postun</code> section that calls <code>/sbin/ldconfig</code>. An example of the correct syntax for this is:
<pre>
%post -p /sbin/ldconfig

%postun -p /sbin/ldconfig
</pre>
Note that this specific syntax only works if <code>/sbin/ldconfig</code> is the only call in <code>%post</code> and <code>%postun</code>. If you have additional commands to run during the scriptlet, call <code>/sbin/ldconfig</code> at the beginning of the scriptlet, like this:
<pre>
%post
/sbin/ldconfig
/usr/bin/foo --add

%postun
/sbin/ldconfig
/usr/bin/foo --remove
</pre>

== Configuration files ==

Configuration files must be marked as such in packages.

As a rule of thumb, use <code>%config(noreplace)</code> instead of plain <code>%config</code> unless your best, educated guess is that doing so will break things. In other words, think hard before overwriting local changes in configuration files on package upgrades. An example case when /not/ to use <code>noreplace</code> is when a package's configuration file changes so that the new package revision wouldn't work with the config file from the previous package revision. Whenever plain <code>%config</code> is used, add a brief comment to the specfile explaining why.

Don't use %config or %config(noreplace) under /usr. /usr is deemed to not contain configuration files in MeeGo.

== Initscripts ==

Currently, only SystemV-style initscripts are supported in MeeGo.

== Desktop files ==

If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window. Installed .desktop files MUST follow the [http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html desktop-entry-spec] , paying particular attention to validating correct usage of Name, GenericName, [http://standards.freedesktop.org/menu-spec/latest/apa.html Categories] ,
[http://www.freedesktop.org/Standards/startup-notification-spec StartupNotify]
entries.

=== Icon tag in Desktop Files ===
The icon tag can be specified in two ways:

* Full path to specific icon file:
<code> Icon=/usr/share/pixmaps/comical.png </code>

* Short name without file extension:
<code> Icon=comical </code>

The short name without file extension is preferred, because it allows for icon theming (it assumes .png by default, then tries .svg and finally .xpm), but either method is acceptable.

=== .desktop file creation ===
If the package doesn't already include and install its own .desktop file, you need to make your own. You can do this by including a .desktop file you create as a Source: (such as Source3: %{name}.desktop) or generating it in the spec file. Here are the contents of a sample .desktop file (comical.desktop):

<pre>
[Desktop Entry]
Name=Comical
GenericName=Comic Archive Reader
Comment=Open .cbr & .cbz files
Exec=comical
Icon=comical
Terminal=false
Type=Application
Categories=Graphics;
</pre>

=== desktop-file-install usage ===
It is not simply enough to just include the .desktop file in the package, one MUST run <code>desktop-file-install</code> OR <code>desktop-file-validate</code> in <code>%install</code> (and have <code>BuildRequires: desktop-file-utils</code>), to help ensure .desktop file safety and spec-compliance. <code>desktop-file-install</code> MUST be used if the package does not install the file or there are changes desired to the .desktop file (such as add/removing categories, etc). <code>desktop-file-validate</code> MAY be used instead if the .desktop file's content/location does not need modification. Here are some examples of
usage:

<pre>
desktop-file-install \
--dir=${RPM_BUILD_ROOT}%{_datadir}/applications \
%{SOURCE3}
</pre>

<pre>
desktop-file-install \
--add-category="AudioVideo" \
--delete-original \
--dir=%{buildroot}%{_datadir}/applications \
%{buildroot}/%{_datadir}/foo.desktop
</pre>

<pre>
desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop
</pre>

== Macros ==
=== Using %{buildroot} and %{optflags} vs $RPM_BUILD_ROOT and $RPM_OPT_FLAGS ===
There are two styles of defining the rpm Build Root and Optimization Flags in a spec file:

{| border="1"
|-
| ||macro style || variable style
|-
|Build Root||%{buildroot}||$RPM_BUILD_ROOT
|-
|Opt. Flags||%{optflags}||$RPM_OPT_FLAGS
|}

There is very little value in choosing one style over the other, since they will resolve to the same values in all scenarios. You should pick a style and use it consistently throughout your packaging.

Mixing the two styles, while valid, is bad from a QA and usability point of view, and should not be done in MeeGo packages.

== Handling Locale Files ==

If the package includes translations, add
<pre>
BuildRequires: gettext
</pre>
If you don't, your package could fail to generate translation files in the buildroot.

MeeGo includes an rpm macro called <code>%find_lang</code>. This macro will locate all of the locale files that belong to your package (by name), and put this list in a file. You can then use that file to include all of the locales. <code>%find_lang</code> should be run in the %install section of your spec file, after all of the files have been installed into the buildroot. The correct syntax for <code>%find_lang</code> is usually:
<pre>
%find_lang %{name}
</pre>
In some cases, the application may use a different "name" for its locales. You may have to look at the locale files and see what they are named. If they are named <code>myapp.mo</code>, then you will need to pass <code>myapp</code> to <code>%find_lang</code> instead of <code>%{name</code>}.
After <code>%find_lang</code> is run, it will generate a file in the active directory (by default, the top level of the source dir). This file will be named based on what you passed as the option to the <code>%find_lang</code> macro. Usually, it will be named <code>%{name}.lang</code>. You should then use this file in the <code>%files</code> list to include the locales detected by <code>%find_lang</code>. To do this, you should include it with the -f parameter to <code>%files</code>.
<pre>
%files -f %{name}.lang
%defattr(-,root,root,-)
%{_bindir}/foobar
...
</pre>
If you are already using the -f parameter for the <code>%files</code> section where the locales should live, just append the contents of <code>%{name}.lang</code> to the end of the file that you are already using with -f. (Note that only one file may be used with <code>%files -f</code>.)

Here is an example of proper usage of <code>%find_lang</code>, in <code>foo.spec</code>:

<pre>
...
%prep
%setup -q

%build
%configure --with-cheese
make %{?_smp_mflags}

%install
make DESTDIR=%{buildroot} install
%find_lang %{name}

%clean
rm -rf %{buildroot}

%files -f %{name}.lang
%defattr(-,root,root,-)
%doc LICENSE README
%{_bindir}/foobar

</pre>

=== Why do we need to use %find_lang? ===

Using <code>%find_lang</code> helps keep the spec file simple, and helps avoid several other packaging mistakes.

* Packages that use <code>%{_datadir}/*</code> to grab all the locale files in one line also grab ownership of the locale directories, which is not permitted.
* Most packages that have locales have lots of locales. Using <code>%find_lang</code> is much easier in the spec file than having to do:
<pre>
%{_datadir}/locale/ar/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/be/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/cs/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/de/LC_MESSAGES/%{name}.mo
%{_datadir}/locale/es/LC_MESSAGES/%{name}.mo
...
</pre>
* As new locale files appear in later package revisions, <code>%find_lang</code> will automatically include them when it is run, preventing you from having to update the spec any more than is necessary.

Keep in mind that usage of <code>%find_lang</code> in packages containing locales is a MUST.

== Scriptlets ==
Great care should be taken when using scriptlets in MeeGo packages. If scriptlets are used, those scriptlets must be sane.

=== Scriptlets requirements ===
Do not use the <code>Requires(pre,post)</code> style notation for scriptlet dependencies, because of two bugs in RPM. Instead, they should be split like this:
<pre>
Requires(pre): ...
Requires(post): ...
</pre>
For more information, see [http://www.redhat.com/archives/fedora-devel-list/2004-April/msg00674.html www.redhat.com] .

=== Running scriptlets only in certain situations ===
When the rpm command executes the scriptlets in a package it indicates if the action preformed is an install, erase, upgrade or reinstall by passing an integer argument to the script in question according to the following:
<pre>
install erase upgrade reinstall
%pre 1 - 2 2
%post 1 - 2 2
%preun - 0 1 -
%postun - 0 1 -
</pre>
This means that for example a package that installs an init script with the <code>chkconfig</code> command should uninstall it only on erase and not upgrade with the following snippet:
<pre>
%preun
if [ $1 -eq 0 ] ; then
/sbin/chkconfig --del %{name}
fi
</pre>
See also <code>/usr/share/doc/rpm-*/triggers</code>, which gives a more formal, generalized definition about the integer value(s) passed to various scripts.

=== Scriplets are only allowed to write in certain directories ===
Build scripts of packages (%prep, %build, %install, %check and %clean) may only alter files (create, modify, delete) under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process) according to the following matrix

{| border="1"
|-
| || /tmp, /var/tmp, $TMPDIR, %{_tmppath} || %{_builddir} || %{buildroot}
|-
|%prep || yes || yes || no
|-
|%build || yes || yes || no
|-
|%install || yes || yes || yes
|-
|%check || yes || yes || no
|-
|%clean || yes || yes || yes
|}

Further clarification: That should hold true irrespective of the builder's uid.

== Use of Epochs ==
The Epoch tag in RPM is to be used only as a last resort, and should be avoided whenever possible. However, it is sometimes necessary to use an Epoch to handle upstream versioning changes or to ease transition from third party repositories.

== Writing a package from scratch ==

See [[Spectacle]]

Spectacle is a great tool for straightforward packages, and we have many of those, hundreds, many of those packages already have been using spectacle happily for a while now. Generally, the 80/20 rule applies here, almost 80% of packages in MeeGo can be converted to this format, probably around 20% will need to stay as is for various reasons.

Spectacle in general helps a lot when you have a package that does:
* configure
* make
* make install

and especially useful when for example you have to manage many build dependencies and patches or for common packaging of perl/python/X packages that usually follows the same packaging work flow. We have plans to add lots of nice features to make packaging easier and more fun with spectacle.

While spectacle has many advanced options to cover all kind of corner cases, it should not be used for complex packages that would require lots of customization, especially now that we support multiple architectures and where we need to apply code and custom scripts to support different scenarios.

Spectacle provides scripts to convert spec files to spectacle, those try to do their best but you SHOULD never just take the output as is and rely on the script, a review of the output is necessary, otherwise you might end up with lots of duplication in the spec file. This is the most common mistake, developers are relying on the output of the conversion script, basically picking some spec file from another distro and converting it. This can lead to major disasters in some cases.

So to summarize:
* It is NOT mandatory to use spectacle
* If you try to convert and find yourself spending more than a few minutes on a package, then probably there is something wrong and you should not be using that or you should RTFM.
* Use it with care, especially when you first import the data from existing spec files or when you first create your YAML file
* Your distro maintainer might send you a note that certain packages you are maintaining could be converted to spectacle easily, but she/he should not reject your package because it does not use spectacle.
* If you find yourself forced to edit the spec file manually for some reason, then either:
** your package is not suitable to be used with spectacle
** or you might want to ask for a feature to support that special case

== Modifying existing Packages ==

If you base a new package on an existing non-MeeGo package, make sure you verify its correctness of the package and the spec file and to understand exactly what has been done to package the software exactly. Do not submit a package without knowing what those strange, but innocent-looking commands do.

In particular, you should

* ensure that original tarballs are self-contained pristine tarballs. The tarball should not contain symlinks that reference outside the tarball root directory
* verify any sources and patches and remove patches or sources that:
** are related to platforms we do not support (example: sparc, ia64, ppc, ...)
** Implement features we do not support (example: selinux)
** Read every patch and understand what it does, if it is needed, put an explanation in the header justifying why the patch is needed.
* verify that the license stated in the spec file matches the actual license of the software,
* skim the summary and description for typos and oddities (see Summary and description ),
* make sure that the correct build root is used,
* ensure that macro usage is consistent and that the macros are available in MeeGo (see Macros ).

Keep old changelog entries to credit the original authors. Entries that are several years old or refer to ancient versions of the software may be erased. If you end up doing radical changes and re-write most of the spec file anyway, feel free to start the changelog from scratch. In other words, use your best judgement.

== Changelogs ==

This section describes the MeeGo policy for RPM changelogs. (Original changelogs included in the original source are not affected by this policy.)

Please consider that a "normal end user with some technical skills" should be able to read and understand an RPM changelog. Changelog entries have to be in reverse chronological order: newer change log entries are listed above older entries, with the first entry being the most recent.

Please bear in mind theat MeeGo changelogs will be automatically parsed to prepare distribution release notes and to report on bugs and CVEs and malformed entries may not be read correctly.

=== General information ===

* MeeGo uses a separate file for package changes which is similar to a debian changelog file. This file is named as the spec file, but ends in *.changes instead of *.spec
* Entries in the changes file should have the following structure:
<pre>
* dow mmm dd yyyy Name Goes Here <your@email.com> - [version]
- comment
- comment

</pre>

Note the following exceptions are noted through observation:
* version is often omitted (such as: alsa-utils 1.0.15-1 -> 1.0.16-1)
* there are multiple changelog entries per version (such as: alsa-utils 1.0.19)
* the hyphen between email and version is often omitted (such as: alsa-utils)
* spaces between name and <email> are omitted (such as: Zhang, Qiang Z<qiang.z.zhang@intel.com> nano)
* name is sometimes omitted (such as: bitstream-vera-fonts nicolas.mailhot at laposte.net)
* <email> is sometimes omitted (such as: binutils Jim Kingdon)
This wide variation in formats makes automation tasks harder than they should be. Please use the correct format.

=== External References ===

Each external reference (bug numbers etc) should be of the form:
"(" + external reference code + bug number +")"

Currently defined:
* MeeGo Bugs : BMC#
* MeeGo Features: FEA#
* Common Vulnerability / Exposure : CVE

==== Bug Numbers in the change log ====

During maintenance of a distribution, every change has to be marked with the correct bug number. Normally this has to be an number from https://bugzilla.meego.com/. Add an entry with bugzilla number and a short description of the bug-summary. For example:
- Removed invalid desktop Category "Application" (BMC#4654).
- Symlink icon to pixmaps dir (BMC#2108)
- Added gnome-ui-properties to control-center (BMC#1960).

New packages related to new features will refer to the corresponding bug number in bugzilla, preceded with an FEA. For example:
- Adding Qt Contacts support FEA#8011

==== CVE numbers in change log ====

As with bug numbers: Add a short description (normally the CVE summary should be enough), the Bugzilla and the CVE number to the changelog entry. Examples:
- Add gdk-pixbuf-226710.patch (BMC#226710), and (CVE-2007-0010).
- More XPM fixes: (CVE-2005-2975) xpm too many colors DoS (BMC#129642)
- fix ~/.dmrc symlink attack (BMC#180704), (CVE-2006-2449)

=== Spec File changes ===
Be as precise as possible! This is especially important if you remove something from the spec file.

* Removing original source code must be declared in spec file with a comment ("useful for FreeBSD only" for example) - not necessary to repeat the comment in specfile.
* Extra commands (for example during %install) can be illustrated with a short comment in spec file
* Adding/Removing packages from Requires/Provides must be described in the changelog

=== Source Code changes ===

Document the most important changes but limit verbosity.

* look into the source changelog and pick up the most important changes for the distribution (changes for other operation systems are not important). What has changed in the new version, usually in the level of detail of a NEWS file, the change log files are usually too long. More than '''10-15 lines''' shouldn't be necessary to describe the most important changes.
* arrange the original changes behind the version update information. Example:
- Update to 1.3.2:
+ fixes memory leak in import function
+ new API command: unlock_client()
+ the following bugs are closed by this new upstream release:
++ ............ [MGN:332]
++ .............[MGN:337]
- split of devel package
* If upstream does not provide a meaningful change log, then only do best effort. Don't waste too much time over it.
* If the upstream tarball really has not changed except for the version number, just the version number in the change log would be fine. Same goes for packages just containing some graphics or theming (unless upstream already provides something that fits). If the upstream changes just consists of "updated translation" or "several bug fixes" even that can be sufficient for a changelog entry (unless these bug fixes contain something you find worth mentioning).

== Packaging Static Libraries ==
Packages including libraries should exclude static libs as far as possible (eg by configuring with ''--disable-static''). Static libraries should only be included in exceptional circumstances. Applications linking against libraries should as far as possible link against shared libraries not static versions.

Libtool archives, ''foo.la'' files, should not be included. Packages using libtool will install these by default even if you configure with ''--disable-static'', so they may need to be removed before packaging. Due to bugs in older versions of libtool or bugs in programs that use it, there are times when it is not always possible to remove *.la files without modifying the program. In most cases it is fairly easy to work with upstream to fix these issues. Note that if you are updating a library in a stable release (not devel) and the package already contains *.la files, removing the *.la files should be treated as an API/ABI change -- ie: Removing them changes the interface that the library gives to the rest of the world and should not be undertaken lightly.

=== Packaging Static Libraries ===
* In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists.

* We want to be able to track which packages are using static libraries (so we can find which packages need to be rebuilt if a security flaw in a static library is fixed, for instance). There are two scenarios in which static libraries are packaged:
# '''Static libraries and shared libraries.''' In this case, the static libraries must be placed in a ''*-static'' subpackage. Separating the static libraries from the other development files in ''*-devel'' allow us to track this usage by checking which packages <code>BuildRequire</code> the ''*-static'' package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries.
# '''Static libraries only.''' When a package only provides static libraries you can place all the static library files in the ''*-devel'' subpackage. When doing this you also must have a virtual Provide for the ''*-static'' package:
<pre>%package devel
Provides: foo-static = %{version}-%{release}</pre>

Packages which explicitly need to link against the static version must <code>BuildRequire: foo-static</code>, so that the usage can be tracked.

* If (and only if) a package has shared libraries which require static libraries to be functional, the static libraries can be included in the ''*-devel'' subpackage. The devel subpackage must have a virtual Provide for the ''*-static'' package, and packages dependent on it must <code>BuildRequire</code> the ''*-static'' package.

=== Staticly Linking Executables ===
* Static linkage is a special exception and should be decided on a case-by-case basis. The packager must provide rationale for linking statically, including precedences where available, to release engineering for approval.

[[Category:Packaging]]

JoelRind

2010-11-02T10:51:36Z

Mythi: /* MeeGo 1.2 Key Contacts: Fix Mikko's email */

=== MeeGo Feature Request Status ===

{| border="1"
! Status / Product
! Core OS
! Handset
! IVI
! SDK
! Netbook
! TV
! Tablet
! TOTAL
|-
|NEW
|55
|130
|10
|133
|0
|0
|0
|328
|-
|INDEFINITION Release=1.2
|96
|30
|0
|0
|0
|3
|0
|129
|-
|ACCEPTED with NO Target Build set
|79
|113
|0
|7
|0
|0
|0
|199
|-
|ACCEPTED with Target Build set
|197
|29
|0
|0
|0
|0
|0
|226
|-
|INDEFINITION Release unspecified
|210
|9
|15
|0
|0
|5
|0
|239
|-
|RESOLVED
|563
|299
|2
|0
|0
|0
|0
|864
|-
|TOTAL
|1200
|610
|27
|140
|0
|8
|0
|1985

|}

===Features sorted by status and owner===

[http://bugs.meego.com/report.cgi?x_axis_field=product&y_axis_field=assigned_to&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=MeeGo+Features&product=MeeGo+Connected+TV+Features&product=MeeGo+Core+OS+Features&product=MeeGo+Handset+Features&product=MeeGo+IVI+Features&product=MeeGo+Netbook+Features&product=MeeGo+SDK+features&product=MeeGo+Tablet+Features&version=unspecified&version=1.2&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&deadlinefrom=&deadlineto=&bug_status=NEW&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=short_desc&type0-0-0=notsubstring&value0-0-0=%5BMASTER%5D NEW by Owner Report]

[http://bugs.meego.com/report.cgi?x_axis_field=product&y_axis_field=assigned_to&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=MeeGo+Features&product=MeeGo+Connected+TV+Features&product=MeeGo+Core+OS+Features&product=MeeGo+Handset+Features&product=MeeGo+IVI+Features&product=MeeGo+Netbook+Features&product=MeeGo+SDK+features&product=MeeGo+Tablet+Features&version=1.2&version=1.2&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&deadlinefrom=&deadlineto=&bug_status=INDEFINITION&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=short_desc&type0-0-0=notsubstring&value0-0-0=%5BMASTER%5D INDEFINITION for Release 1.2 by Owner Report]

[http://bugs.meego.com/report.cgi?x_axis_field=product&y_axis_field=assigned_to&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=MeeGo+Features&product=MeeGo+Connected+TV+Features&product=MeeGo+Core+OS+Features&product=MeeGo+Handset+Features&product=MeeGo+IVI+Features&product=MeeGo+Netbook+Features&product=MeeGo+SDK+features&product=MeeGo+Tablet+Features&version=1.2&version=unspecified&version=1.2&target_milestone=---&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&deadlinefrom=&deadlineto=&bug_status=ACCEPTED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=short_desc&type0-0-0=notsubstring&value0-0-0=%5BMASTER%5D ACCEPTED in 1.2 with NO TB by Owner Report]

[http://bugs.meego.com/report.cgi?x_axis_field=product&y_axis_field=assigned_to&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=MeeGo+Features&product=MeeGo+Connected+TV+Features&product=MeeGo+Core+OS+Features&product=MeeGo+Handset+Features&product=MeeGo+IVI+Features&product=MeeGo+Netbook+Features&product=MeeGo+SDK+features&product=MeeGo+Tablet+Features&version=1.2&version=1.2&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&deadlinefrom=&deadlineto=&bug_status=ACCEPTED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=target_milestone&type0-0-0=notsubstring&value0-0-0=---&field0-1-0=short_desc&type0-1-0=notsubstring&value0-1-0=%5BMASTER%5D ACCEPTED in 1.2 with TB by Owner Report]

[http://bugs.meego.com/report.cgi?x_axis_field=product&y_axis_field=assigned_to&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=MeeGo+Features&product=MeeGo+Connected+TV+Features&product=MeeGo+Core+OS+Features&product=MeeGo+Handset+Features&product=MeeGo+IVI+Features&product=MeeGo+Netbook+Features&product=MeeGo+SDK+features&product=MeeGo+Tablet+Features&version=unspecified&target_milestone=---&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&deadlinefrom=&deadlineto=&bug_status=INDEFINITION&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=short_desc&type0-0-0=notsubstring&value0-0-0=%5BMASTER%5D INDEFINITION Release "unspecified" by Owner Report ]

[http://bugs.meego.com/report.cgi?x_axis_field=product&y_axis_field=assigned_to&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=MeeGo+Features&product=MeeGo+Connected+TV+Features&product=MeeGo+Core+OS+Features&product=MeeGo+Handset+Features&product=MeeGo+IVI+Features&product=MeeGo+Netbook+Features&product=MeeGo+SDK+features&product=MeeGo+Tablet+Features&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&deadlinefrom=&deadlineto=&bug_status=RESOLVED&bug_status=RELEASED&bug_status=VERIFIED&bug_status=CLOSED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= RESOLVED ]

===MeeGo 1.2 Requirements process trend indicators===

'''MeeGo 1.2 Core'''

{| border="1"
! Date / Status
! New
! Indef / 1.2
! Accepted - No TB
! Accepted w/TB
! Indef/unspecified
! Resolved
! TOTAL
|-
|10/22/2010
|113
|235
|134
|160
|131
|477
|-
|10/25/2010
|101
|150
|134
|164
|183
|480
|-
|10/26/2010
|78
|105
|144
|162
|195
|493
|-
|10/27/2010
|28
|96
|112
|161
|216
|568
|-
|10/28/2010
|28
|94
|89
|184
|217
|564
|-
|10/29/2010
|28
|94
|89
|184
|218
|563
|-
|11/1/2010
|55
|96
|79
|197
|210
|563
|}

'''MeeGo 1.2 Handset

{| border="1"
! Date / Status
! New
! Indef / 1.2
! Accepted - No TB
! Accepted w/TB
! Indef/unspecified
! Resolved
! TOTAL
|-
|10/25/2010
|95
|15
|92
|8
|6
|282
|-
|10/26/2010
|95
|19
|94
|6
|8
|289
|-
|10/27/2010
|96
|29
|135
|4
|8
|296
|-
|10/28/2010
|96
|32
|121
|18
|8
|300
|-
|10/29/2010
|130
|30
|121
|18
|9
|299
|-
|11/1/2010
|130
|30
|113
|20
|9
|299
|}

[[File:FEA-Nov01-1.png]]

===MeeGo 1.2 Key Contacts===
'''MeeGo 1.2 Program Office'''

* Core Program Manager: [mailto:Makoto.Sugano@nokia.com Makoto Sugano]
* Core Product Manager: [mailto:Gavin.Hindman@intel.com Gavin Hindman]
* Core Architect: [mailto:Sakari.Poussa@nokia.com Sakari Poussa]
 
* Handset Program Manager: [mailto:Pierre.j.blouin@intel.com Pierre Blouin]
* Handset Product Manager: [mailto:Sami.Pienmaki@nokia.com Sami Pienimaki]
* Handset Architect: [mailto:mikko.k.ylinen@nokia.com Mikko Ylinen]
 
* In-vehicle Program Manager: [mailto:joel.clark@intel.com Joel Clark]
* In-vehicle Product Manager: TBD
* In-vehicle Architect: [mailto:Tom.Counihan@intel.com Tom Counihan]

'''Core Technologists'''
* API Core
** Qt: [mailto:Adrian.Constantin@nokia.com Adrian Constantin]
** Haptic: [mailto:Kaustabh.Debbarman@nokia.com Kaustabh Debbarman]
** Publish & Subscribe: [mailto:Naba.Kumar@nokia.com Naba Kumar]
** Text to Speech: No resources allocated
** DRM: Not part of MeeGo.com
* Device Sync: [mailto:Naba.Kumar@nokia.com Naba Kumar]
* Kernel: [mailto:Arjan.van.de.ven@intel.com Arjan Van De Ven]
* Location: Intel
* Media Subsystem
** Video & Editing: [mailto:Kaustabh.Debbarman@nokia.com Kaustabh Debbarman]
* Package Management:Intel
* Policy: [mailto:Kaustabh.Debbarman@nokia.com Kaustabh Dabbarman]
* WRT: TBD
* Web Services: Intel
* Libmeegotouch: [mailto:Kaustabh.Debbarman@nokia.com Kaustabh Dabbarman]

Architecture

2010-11-02T09:21:25Z

Mythi: /* Upcoming Features */

== MeeGo Architecture ==

MeeGo architecture team is responsible for defining and managing the MeeGo architecture. MeeGo architecture consists of Core OS layer and number of UX verticals on top the Core OS layer. The architecture team decides which component to use for the functionality needed in MeeGo with the objective of consistency inside the Core OS and to the applications that run above it.

== Team ==

* '''[http://meego.com/users/arjan Arjan van de Ven]''', Chief Architect, responsible for MeeGo architecture
* '''[http://meego.com/users/poussa Sakari Poussa]''', Core OS Architect, responsible for Core OS architecture
* '''[http://meego.com/users/mythi Mikko Ylinen]''', Handset UX Architect, responsible for Handset UX architecture
* '''[http://meego.com/users/sunilsaxena Sunil Saxena]''', Core OS Architect, responsible for Core OS architecture

== Communication ==

* [http://lists.meego.com/listinfo/meego-architecture MeeGo architecture mailing list]

== Process ==

* Architecture team meets once a week. Currently the meetings are not public.
* Agenda and minutes of the meetings will be posted to the meego-architecture mailing list
* Anyone can propose topics to the architecture team agenda
* Architecture topics can and should be discussed on meego-architecture mailing list
* Architecture team is responsible of making the decision in case consensus is not reached

=== Process Improvement Topics ===

* How to make the architecture meetings open. Not all the topics can be open but most can be. Examples of non-open parts includes topics which involves IPR, legal, patent, business, product or schedule sensitive material.

== Documentation ==

* Developer Documentation: APIs, tutorials, videos, examples ([[http://developer.meego.com]]), to be published soon
* Architecture Documentation: High level architecture pictures and description ([[http://meego.com/developers/meego-architecture]])
* Developer and Subsystem Documentation: Detailed technical description of each MeeGo subsystem. Guidelines for developers working on MeeGo. ([[http://wiki.meego.com/Architecture/Documentation]])

== Meetings ==

* [[Architecture/Meetings]] - Meetings - agenda, minutes

== Upcoming Features ==

MeeGo Bugzilla lists the following features for MeeGo 1.2. However, no technical solution is agreed yet (some proposals exist, though).

* Display backlight and keyboard backlight control: [http://bugs.meego.com/show_bug.cgi?id=5525 5525], [http://bugs.meego.com/show_bug.cgi?id=5526 5526], [http://bugs.meego.com/show_bug.cgi?id=5527 5527], [http://bugs.meego.com/show_bug.cgi?id=5528 5528]
** Proposal 1: Maemo 6 MCE
*** ''MCE provides activity monitoring and notifications via D-Bus, controls display and backlight, ALS reading and display tuning, airplane mode''

* Sharing: [http://bugs.meego.com/show_bug.cgi?id=8179 8179], [http://bugs.meego.com/show_bug.cgi?id=8180 8180], [http://bugs.meego.com/show_bug.cgi?id=8181 8181]
** Proposal 1: Maemo6 Sharing framework
*** ''Sharing framework provides a unified API for sharing files via, e.g., BT, email, web services. It includes webupload engine and an API for transfer UI''

* Qt style APIs (that are not covered by Qt Mobility) for display backlight control, alarm/time, heartbeat, system state, thermal
** Proposal 1: Maemo6 QmSystem
*** ''QmSystem provides Qt style public APIs for various system services that are not covered by Qt Mobility''

* Profiles: [http://bugs.meego.com/show_bug.cgi?id=5771 5771], [http://bugs.meego.com/show_bug.cgi?id=5750 5750], [http://bugs.meego.com/show_bug.cgi?id=2889 2889]
** Proposal 1: Maemo6 profiled
*** ''profiled provides a daemon and libraries to access and control profiles related data in the device. The libprofile (C) and libprofile-qt (Qt) are interfaces for the profile client to connect to the server using D-Bus. The profiled data is stored in ‘ini’ files which can be customized per different releases.''

* Ringtones+feedback: [http://bugs.meego.com/show_bug.cgi?id=2889 2889]
** Proposal 1: Maemo6 NGF (non-graphic feedback)
*** ''The device has functionality to alert user of a call, alarms and notification (SMS, email, chat, system update) events. Events may or may not have a graphical part and it may have different behavior depending on the system state. Example of this is receiving an SMS message when there is no other activity and SMS message during a call. NGF provides a unified API for apps to request logical events. The actions (e.g,. play/show LED+audio+vibra) are combined in NGF and consistent look&feel is provided''.

== Tools ==

Architecture tools

* Architecture navigation tool - able to browse meego packages and visually see the dependencies (coming in Nov)