Directrices de empaquetado y cumplimiento de MeeGo

Visión general rápida

Estos son los pasos de un vistazo.

  1. Introducción
  2. Cumplimiento 3.1.1 - Denominación
  3. Cumplimiento 3.1.2 - Dependencias
  4. Cumplimiento 3.1.3 - Integración con RPM
  5. Cumplimiento 3.1.4 - Diseño en el sistema de archivos
  6. Cumplimiento 3.1.5 - Integración de escritorio
  7. Cumplimiento 3.2.1 - Ejecutables de aplicaciones compatibles
  8. Cumplimiento 3.2.2 - Uso de conjuntos de instrucciones dependientes de la implementación
  9. Enhorabuena

Introducción

Antes de comenzar este artículo, debe echar un vistazo a la página de Calidad/cumplimiento de MeeGo. Esta sección es una introducción detallada al estándar de cumplimiento para aplicaciones y dispositivos. También describe cómo configurar las herramientas de cumplimiento para que pueda probar su propia aplicación antes de enviarla a la tienda AppUp.

En este artículo describiré lo que debe hacer para crear un paquete de instalación de RPM que sea compatible con MeeGo y esté preparado para enviarse a la tienda AppUp.

Estos son los puntos de cumplimiento principales. Para obtener más información, asegúrese de consultar el documento de cumplimiento.


Especificaciones de cumplimiento 3.1.1 Denominación

Un nombre de aplicación debe empezar con uno de los nombres de dominio totalmente cualificados de los propietarios en minúsculas, en orden inverso, y finalizar con el nombre de la aplicación (por ejemplo, com.nombre_empresa.nombre_aplicación).

Este requisito sirve para ayudar a las aplicaciones a evitar conflictos de denominación y garantiza que todos los que envíen una aplicación a la tienda AppUp tiene un nombre reconocible y comercializable para el archivo de instalación.


Especificaciones de cumplimiento 3.1.2 Dependencias

Los paquetes de aplicaciones DEBEN “requerir” (en terminología de RPM) todos los componentes del sistema que sean necesarios para que funcionen. PUEDEN omitir dependencias opcionales, si esa omisión no afecta a la capacidad de la aplicación de funcionar de forma fácil para el usuario, es decir, omitir una dependencia no debe tener el efecto de permitir que la aplicación se instale con éxito pero luego no funcione correctamente. Los paquetes de aplicaciones NO PUEDEN depender de características que están fuera de esta especificación, ya que esto afectaría a la capacidad de instalación de la aplicación.

Se permiten dependencias en componentes de sistema en términos de nombres de paquete o en términos de características.

El formato de paquete RPM permite que el desarrollador/empaquetador especifique otros paquetes de RPM como dependencias de instalación. Este requisito indica simplemente que, si tiene que instalar otros paquetes para que funcionen sus aplicaciones, debe requerirlos. La penúltima frase es muy importante. Permítame que la reformule.

Los paquetes de aplicaciones NO PUEDEN depender de características que están fuera de esta especificación (en referencia a la Especificación de cumplimiento), ya que esto afectaría a la capacidad de instalación de la aplicación.

Esto quiere decir que, si tiene dependencias de instalación, tiene que saber si forman parte de los paquetes especificados por la especificación de cumplimiento de MeeGo. Si forman parte de la especificación, estarán presentes en cualquier dispositivo compatible con MeeGo y solo tiene que requerirlos en RPM. Si el paquete de terceros que necesita no se indica en la especificación de cumplimiento, tiene que empaquetar la biblioteca de terceros. Esto significa que tampoco se permite que aplicaciones compatibles con MeeGo utilicen repositorios de terceros. En vez de usar un repositorio de terceros, descargue las bibliotecas y empaquételas en su RPM.


Especificaciones de cumplimiento 3.1.3 Integración con RPM

Los paquetes de aplicaciones deben crearse de manera que el sistema de gestión de paquetes sepa cuáles son los archivos que se instalan. Las consultas en los paquetes instalados, utilizando herramientas de gestión de paquetes estándar, debe funcionar según lo esperado.

Los paquetes que instalan todos los archivos en un script posterior a la instalación no son compatibles. La aplicación debe desinstalarse limpiamente, dejando el sistema en el mismo estado en que estaba antes de la instalación (salvo los archivos o configuraciones agregados por los usuarios).

Simplemente significa que la instalación y la desinstalación deben realizarse de la manera habitual de RPM y cuando se realiza una desinstalación, debe eliminarse todo lo que se instaló con ella.

Estos son algunos ejemplos de cómo RPM debe poder utilizar los archivos de instalación.

Ejemplos:

  • Buscar el paquete al que pertenece un archivo: $ rpm –q –-file nombre_archivo
  • Generar una lista de todos los archivos instalados por un paquete: $ rpm –ql nombre_paquete

Especificaciones de cumplimiento 3.1.4 Diseño en el sistema de archivos

La aplicación debe instalarse en /opt/nombre_paquete/ y, si es necesario, en los directorios /etc/opt/nombre_paquete/ y /var/opt/nombre_paquete/. Los archivos de configuración de todo el sistema deben colocarse en el directorio /etc/opt/nombre_paquete. Los datos de variables de un paquete como, por ejemplo, archivos de bloqueo, archivos de caché, etc. se colocarán en el directorio /var/opt/nombre_paquete en vez de hacerlo directamente en /var, a menos que sea necesaria una ubicación específica para que la aplicación o el sistema funcione correctamente. Los archivos específicos del usuario se almacenarán en el directorio ~/.config/nombre_paquete. Lo que se pretende con el uso de estas reglas es evitar conflictos de nombre de archivo entre paquetes de aplicaciones y archivos de sistema, al definir que determinadas partes del sistema de archivos sean exclusivas de esa aplicación.

Este requisito indica simplemente que los archivos binarios, archivos de configuración del sistema, archivos tales como los de bloqueo y caché, y los archivos específicos del usuario tengan todos sus directorios correspondientes.


Especificaciones de cumplimiento 3.1.5 Integración de escritorio

Debe instalarse un archivo .desktop en /usr/share/applications y debe contener valores al menos para los campos siguientes: Name, Comment, [Exec o Link], Icon, Type y Categories. El archivo de imagen especificado en el campo Icon del archivo .desktop debe estar en formato SVG o PNG. En el caso del formato PNG, se proporcionarán los tamaños siguientes: 16x16, 32x32, 64x64 y 128x128.

La primera parte de este requisito indica que debe crear un archivo .desktop para la aplicación. Un archivo .desktop almacena detalles acerca de cómo debe iniciarse una aplicación, incluido el nombre de aplicación, las variables de entorno, la ubicación del icono, etc. La Especificación de la entrada de escritorio es mantenida por freedesktop.org.

Este es un archivo .desktop de ejemplo, en este caso el archivo .desktop para la aplicación meego-help:

[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;

La segunda parte de este requisito indica los tamaños de los iconos que deben proporcionarse con la aplicación.


Cumplimiento 3.2.1 Ejecutables de aplicaciones compatibles

Todos los archivos ejecutables binarios compatibles y bibliotecas compartidas de MeeGo deberán tener el formato ELF, como se describe en la sección 2.4.1. Solo deben importar interfaces externas de las fuentes siguientes:

  • bibliotecas compartidas suministradas como parte del paquete de aplicaciones
  • bibliotecas compartidas de MeeGo Core, si la interfaz forma parte de las interfaces públicas de esa biblioteca

Además, el ejecutable puede utilizar interfaces públicas de bibliotecas compartidas específicas de un perfil de MeeGo pero, en este caso, la aplicación solo será compatible con dicho perfil.

Si el ejecutable es un complemento de un componente del sistema de MeeGo, puede importar interfaces de un ejecutable del componente del sistema y de bibliotecas compartidas que se carguen como parte de dicho ejecutable.

Este requisito reitera que una aplicación compatible con MeeGo solo debe vincularse con bibliotecas compartidas de MeeGo Core. Esto es debido a que estas bibliotecas ya están instaladas en cualquier dispositivo compatible con MeeGo.

La frase de que los ejecutables deben tener el formato ELF solo hace referencia a los archivos binarios de aplicación. Los lenguajes de script como Python, Perl, Ruby, etc... son, sin duda, aceptables.

Los perfiles de MeeGo, a veces denominados "Verticales", son la combinación de los paquetes de instalación de MeeGo Core y los paquetes de instalación de perfiles concretos. Los distintos perfiles incluyen actualmente MeeGo Netbook, MeeGo Tablet, MeeGo IVI (in-vehicle infotainment) y MeeGo Handset. Si una aplicación utiliza unas API proporcionadas por el perfil MeeGo Tablet, por ejemplo, esta aplicación será compatible con tablets y no con los demás perfiles.

La última frase de la sección 3.2.1 menciona que, si se crea una aplicación utilizando componentes, vincularse a ellos está permitido por las directrices de cumplimiento de MeeGo


Cumplimiento 3.2.2 Uso de conjuntos de instrucciones dependientes de la implementación

Un archivo binario o una biblioteca compartida de aplicación PUEDE utilizar extensiones de arquitectura de CPU y características específicas de la implementación al crear los archivos binarios. Si dicho uso limitase la portabilidad de la aplicación, esta deberá identificar claramente las restricciones impuestas como resultado; los repositorios o tiendas de aplicaciones deben poder filtrar los dispositivos que no sean aplicables. No se especifica el mecanismo para ello.

Si utiliza conjuntos de instrucciones específicos de la CPU, debe indicar la restricción de su aplicación.


Conclusión

Hemos examinado más a fondo los detalles de las directrices de cumplimiento de MeeGo para aplicaciones y esperamos haberlos explicado con claridad. Si hay otras cuestiones sobre las directrices de cumplimiento, eche un vistazo a estos recursos.


La administración de energía para los próximos dispositivos de tablet MeeGo incluye algunas recomendaciones adicionales. Consulte los enlaces siguientes para obtener más información sobre la administración de energía y los cambios necesarios en el archivo .desktop para cumplir esta recomendación.
Preguntas más frecuentes sobre la administración de energía
Administración de energía - Entrada de archivo desktop











0