Reply to comment
MeeGo Packaging and Compliance Guidelines
Quick Overview
Here are the steps at a glance.
- Introduction
- Compliance 3.1.1 - Naming
- Compliance 3.1.2 - Dependencies
- Compliance 3.1.3 - Integration with RPM
- Compliance 3.1.4 - Layout in Filesystem
- Compliance 3.1.5 - Desktop Integration
- Compliance 3.2.1 - Compliant Application Executables
- Compliance 3.2.2 - Use of Implementation Dependent Instruction Sets
- Congratulations
Introduction
Before starting this article, you should take a look at the MeeGo Quality/Compliance Page. This section will introduce you to the compliance standard in detail for applications and devices. It will also describe how to setup the compliance tools so that you can test you're own application before submitting them to the AppUp store.
In this article, I will describe what you must do to create an RPM installation package that is MeeGo compliant and ready to submit to the AppUp store.
Here are the main points of compliance. For more information be sure to look at the compliance document.
Compliance Spec 3.1.1 Naming
An application package name shall begin with one of the owners' fully qualified domain names in lower case, in reverse order, and end with the application name (such as, com.companyname.appname).
This requirement is to help applications avoid naming clashes and makes sure that everyone who submits an application to the AppUp Store has a recognizable and marketable name for the installation file.
Compliance Spec 3.1.2 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.
The RPM package format allows the developer/packager to specify other RPM packages as installation dependencies. This requirement simply states that if you need other packages to be installed for your applications to run then you must require them. The second to last sentence is a very important one. Allow me to restate it.
Application packages MAY NOT depend on features outside this specification (referring to the Compliance Specification) as this would affect the ability of the application to install.
This means that if you have installation dependencies, you need to know whether they are part of the packages specified by the MeeGo compliance spec. If they are part of the specification then they will be present on any MeeGo compliant device and you can simply require them in the RPM. If the third party package that you need is not specified in the compliance specification, then you need to bundle the third party library. This also means that third-party repositories are not allowed to be used by MeeGo compliant applications. Instead of using a third-party repository download the libraries and bundle them into your RPM.
Compliance Spec 3.1.3 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.
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).
This client it simply means that installing and uninstalling should be done in the usual RPM manners, and what and uninstall is performed it should remove everything that came with it.
Here are some examples of how rpm should be able to use your install files.
Examples:
- Find the package that a file belongs to: $ rpm –q –-file filename
- List all files installed by a package: $ rpm –ql packagename
Compliance Spec 3.1.4 Layout in Filesystem
An application shall be installed to /opt/packagename/ and, if necessary to the /etc/opt/packagename/ and /var/opt/packagename/ directories. System wide configuration files shall be placed in the /etc/opt/packagename directory rather than directly in operate correctly. Variable data from a package, such as lock files, cached files, etc. shall be placed in the /var/opt/packagename directory rather than directly in /var, unless a specific location is necessary for the application or system to operate correctly. User specific files shall be stored in the ~/.config/packagename directory. The rationale for these rules is to avoid filename clashes between application packages and with system files, by defining portions of the filesystem certain to be unique to that application.
This requirements simply states that binaries, system configuration files, files such as lock files and cached files, and user specific files all have their appropriate directories.
Compliance Spec 3.1.5 Desktop Integration
A .desktop file shall be installed under /usr/share/applications, and contain values for at least the following fields: Name, Comment, [Exec or Link], Icon, Type, and Categories. The picture file specified in the Icon field of the .desktop file must be either SVG or PNG format. In the case of PNG format, the following sizes shall be provided: 16x16, 32x32, 64x64, and 128x128.
The first part of this requirement states that you must create .desktop file for your application. A .desktop file stores details about how an application is to be launched, including the application name, environment variables, the location of the icon and more. The Desktop Entry Specification is maintained by freedesktop.org.
Here is a sample .desktop file in this case the .desktop file for the MeeGo-help application:
[Desktop Entry]
Version=1.0
Name=MeeGo Help
Comment=MeeGo Help Application
Type=Application
Icon=moblin-logo-icon
Terminal=false
Exec=MeeGo-help
Categories=Utility;
The second part of this requirement states the sizes of icons that must be provided with the application.
Compliance 3.2.1 Compliant Application Executables
All MeeGo compliant binary executable files and shared libraries shall be in the ELF format, as described in section 2.4.1. 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.
This requirement again reiterates that a MeeGo compliant application must link only to MeeGo Core shared libraries. This is because these libraries are already installed on any device that is MeeGo compliant.
The statement that executables must be in ELF format refers only to application binary files. Scripting languages like Python, Perl, Ruby, etc ... are certainly acceptable.
MeeGo profiles, sometimes called "Verticals," are the combination of the MeeGo Core installation packages and a particular profiles' installation packages. The different profiles currently include MeeGo Netbook, MeeGo Tablet, MeeGo IVI (in-vehicle infotainment) and MeeGo Handset. If an application uses APIs that are provided by the MeeGo Tablet profile, for example, then this application will be compliant for tablets and not for the other profiles.
The last sentence of the section 3.2.1 mentions that if an application is built using components then linking to them is allowed by the MeeGo compliance guidelines
Compliance 3.2.2 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.
If you use CPU specific instruction sets, then you must state the restriction of your application.
Conclusion
We've taken a closer look at the particulars of the MeeGo compliance guidelines for applications and hopefully explained them in a clear manner. If there are any other questions about the compliance guidelines then take a look at these resources.
- MeeGo Quality and Compliance Wiki page
- A seminar session on MeeGo compliance in 2010
- The MeeGo Forums
Power Management for upcoming MeeGo tablet devices introduces some additional recommendations. Please refer to the links below for more information on Power Management and changes required to the .desktop file to comply with this recommendation.
Power Management FAQs
Power Management - Desktop file entry
