La guía para desarrolladores de snap sobre cómo migrar a nuevas bases

Ubuntu mayo 8, 2021

Hace un par de semanas publicamos un artículo acerca de Ubuntu 16.04 que ingresa al Mantenimiento de seguridad extendido (ESM) y las implicaciones de este cambio para los editores de instantáneas. Hablamos sobre las diferentes opciones disponibles para desarrolladores y editores que aún pueden confiar en las bases más antiguas en su proceso de compilación: tokens gratuitos de Ubuntu Advantage (UA), Launchpad y Snapcraft Build Service, soporte de snapcraft para la base de ESM y otros.

Sin embargo, para la mayoría de los editores, la migración de la base de ESM (core) a core18 y core20 ofrece el mayor grado de flexibilidad. Esto les permitirá crear instantáneas con las últimas versiones de Snapcraft, disfrutar de las mejoras actuales y futuras en el ecosistema y brindar a sus usuarios la mejor experiencia posible. Hoy, en esta guía, describimos varios consejos prácticos comunes para la migración a bases más nuevas.

Los nombres de los paquetes pueden haber cambiado

Cuando crea un complemento, especifica una lista de paquetes opcionales necesarios en el momento de la compilación y el tiempo de ejecución. Estos se definen en las secciones build-packages y stage-packages del archivo snapcraft.yaml.

Sin una base o un núcleo especificados, snapcraft usa paquetes disponibles en el archivo Ubuntu 16.04 LTS en los pasos de compilación y etapa del ciclo de vida de snap. De manera similar, si usa la base core18, snapcraft usa paquetes del archivo Ubuntu 18.04 LTS y, con la base core20, consume paquetes del archivo Ubuntu 20.04 LTS. Esto significa que si confía en un nombre y una versión de paquete específicos, podría cambiar entre estas diferentes versiones.

Por ejemplo, con el Irssi snap, un cambio a los paquetes de escenario se vería de la siguiente manera:

-     - libperl5.22
+     - libperl5.26

En este ejemplo, el nombre del paquete de la biblioteca Perl cambió debido a un salto de versión. La forma más fácil de descubrir el “delta” en los paquetes y sus versiones es crear un nuevo complemento en el sistema base de destino (18.04 o 20.04), examinar cualquier falla en tiempo de ejecución y actualizar cada paquete no resuelto.

El cambio de palabra clave de arquitectura

Una diferencia importante en el cambio a bases más nuevas es que la palabra clave arquitectura ahora define un conjunto de ambos build y ejecutar arquitecturas.

architectures:
  - build-on: amd64
    run-on: amd64

También es importante prestar atención al software de 32 bits. Las instantáneas que producen compilaciones i386 son compatibles durante la vida útil de Ubuntu 16.04 LTS o Ubuntu 18.04 LTS cuando se utilizan las instantáneas core o core18 como base. Sin embargo, base: core20 no soporta la arquitectura i386. Con core20, las arquitecturas compatibles son amd64, arm64, armhf, ppc64el y s390x.

Variables de entorno y rutas de código rígido

Las variables de entorno se utilizan a menudo en instantáneas para garantizar que los binarios puedan encontrar módulos cargables o bibliotecas incluidas en la instantánea en tiempo de ejecución. En algunos casos, las variables de entorno pueden incluir rutas codificadas que contienen números de versión específicos y deberán cambiarse. Una vez más, si miramos el Irssi quebrar:

   environment:
-        PERL5LIB:  "$SNAP/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/perl-base/:$SNAP/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/perl5/5.22/:$SNAP/usr/share/perl5/:$SNAP/usr/share/perl/5.22.1/:$SNAP/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/perl/5.22/:$SNAP/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/perl/5.22.1/"
+        PERL5LIB:  "$SNAP/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/perl-base/:$SNAP/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/perl5/5.26/:$SNAP/usr/share/perl5/:$SNAP/usr/share/perl/5.26.1/:$SNAP/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/perl/5.26/:$SNAP/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/perl/5.26.1/"

Partes remotas

La funcionalidad de piezas remotas ha quedado obsoleta. En el pasado, las instantáneas podían usar partes remotas para compartir la configuración en múltiples sans, para reducir la complejidad local de snapcraft.yaml. Las partes remotas se definirían en ubicaciones distintas del directorio local y se incorporarían en el momento de la compilación.

En el futuro, las partes remotas deben pegarse directamente en snapcraft.yaml o referenciarse desde su repositorio de origen. Por ejemplo, una parte remota pegada en el Señor rescate quebrar.

parts:
  mrrescue:
-    after:
-      - desktop-glib-only
+   desktop-glib-only:
+     build-packages:
+       - libglib2.0-dev
+      plugin: make
+      source: https://github.com/ubuntu/snapcraft-desktop-helpers.git
+      source-subdir: glib-only
+     stage-packages:
+       - libglib2.0-bin

Extensiones de Snapcraft

La migración de piezas remotas se enlaza muy bien con las extensiones de Snapcraft, un nuevo concepto introducido en el ciclo de vida de la compilación instantánea. Extensiones de Snapcraft permiten a los desarrolladores simplificar sus instantáneas mediante el uso de paquetes de códigos comunes, que ocultan y abstraen gran parte del contenido que normalmente se usaría en los archivos snapcraft.yaml. De esta manera, los desarrolladores pueden evitar tareas repetitivas, utilizar una plantilla común y coherente para las compilaciones de sus aplicaciones y hacer un mejor uso de las prácticas conocidas, que en última instancia ahorran tiempo y esfuerzo, y pueden dar como resultado instantáneas de menor tamaño y con tiempos de inicio mejorados.

Al migrar a núcleos (y extensiones) más nuevos, los desarrolladores deben prestar atención a la sintaxis, así como asegurarse de usar la versión correcta de la extensión para su compilación. Primero, veamos un chasquido que no usó Una extensión.

parts:
  xonotic:
-    after:
-      - desktop-glib-only
apps:
  xonotic:
-    command: desktop-launch $SNAP/Xonotic/xonotic-linux-sdl.sh
+    extensions: [gnome-3-34]
+    command: Xonotic/xonotic-linux-sdl.sh

En el ejemplo anterior, eliminamos la referencia a una parte remota desktop-glib-only y, en su lugar, declaramos el uso de la extensión gnome-3-34, que reemplaza la funcionalidad de la parte remota (además de proporcionar beneficios adicionales).

Nombres de extensiones de Snapcraft

También es importante prestar atención a la convención de nomenclatura, ya que no todas las extensiones (y sus versiones específicas) funcionan en todas las bases. Por ejemplo, en core18, si deseas usar la extensión GNOME, debe usar la extensión gnome-3-34, mientras que en core20, debe usar gnome-3-38. Puedes leer el Extensiones compatibles página para más detalles.

Como ejemplo, Fortaleza enana usa la extensión GNOME core-20-only:

parts:
  tarball:
-     after: [desktop-gtk3]
apps:
  dwarffortress:
-    command: desktop-launch $SNAP/wrapper.sh
+    extensions: [gnome-3-38]
+    command: wrapper.sh

Cambian las interfaces de audio

Para las aplicaciones que reproducen o graban audio, los nombres de la interfaz han cambiado. Anteriormente, el La interfaz pulseaudio se utilizó tanto para la reproducción como para la grabación de audio. Esto ha sido reemplazado por reproducción de audio y grabación de audio, respectivamente:

apps:
  xonotic:
    Plugs:
-      pulseaudio
+      audio-playback     

Los editores de Snap deben tener en cuenta que, por razones de privacidad y seguridad, la interfaz de grabación de audio no se conecta automáticamente. Para una funcionalidad perfecta (necesaria) de un complemento que se basa en la grabación de audio, los editores deben crear una solicitud en el foro de Snapcraft.

Cambios en el nombre del complemento

Varios complementos de Snapcraft diferentes han cambiado, y las instantáneas que dependen de ellos requerirán algunas modificaciones. En general, los cambios de complementos se pueden consultar con el comando snapcraft help –base :

$ snapcraft help npm --base core20
Displaying help for the 'npm' plugin for 'core20'.
[...]

También puede enumerar complementos para una base específica con snapcraft list-plugins –base , por ejemplo:

$ snapcraft list-plugins --base core20
Displaying plugins available for 'core20'
autotools  catkin  catkin-tools  cmake  colcon  dump  go  make
meson nil  npm  python  qmake  rust

Si no está seguro de qué hacer, intente construir su complemento con solo core18 / 20 declarado. Snapcraft le proporcionará errores significativos que le ayudarán a realizar las modificaciones necesarias en su archivo snapcraft.yaml.

EnchufarCentroCore20Comentarios
nodo / npmnodejsnpm
nodo / npmmotor de nodonpm-node-versionEspecifique la versión de npm ascendente que se utilizará en el momento de la compilación
autotoolsconfigflagsautotools-configure-parámetros
irgo-importpathgo-channel

Complemento Npm ejemplo de cambios de sintaxis:

parts:
  wethr:
-    plugin: nodejs
+    plugin: npm
parts:
  wethr:
-    node-engine: "10.14.1"
+    npm-node-version: "10.14.1"

Complemento de Autotools ejemplo de cambios de sintaxis:

parts:
  libconfuse:
    plugin: autotools
-    configflags: ['--prefix=/usr', '--disable-examples', '--disable-static']
+    autotools-configure-parameters: ['--prefix=/usr', '--disable-examples', '--disable-static']

Ir plugin ejemplo de cambios de sintaxis:

parts:
  slack-term:
    plugin: go
-      go-importpath: github.com/erroneousboat/slack-term
+      go-channel: latest/stable

Definiciones de la aplicación

También hay varios cambios en la definición de la aplicación. Snapcraft ahora requiere que se especifiquen rutas explícitas para los binarios enumerados en la sección de aplicaciones:

apps:
  wethr:
-    command: wethr
+    command: bin/wethr

Además, en lugar de especificar un comando seguido de una larga lista de ejecutables separados por espacios, ahora se pueden enumerar con la opción de cadena de comandos. Por ejemplo, en el Chasquido de átomo ejemplo:

apps:
  atom:
-    command: bin/launcher ${SNAP}/usr/share/atom/atom
+    command-chain:
+      - bin/launcher
+    command: usr/share/atom/atom

Scripts de versión

El nivel superior versión-script La opción ha quedado obsoleta a favor de adoptar-info. Esto requiere que especifique adopt-info con una referencia a la parte en la que se pueden configurar los datos de la versión (y algunos otros metadatos). Dentro de la sección de piezas, puede utilizar snapcraftctl set-version para definir el número de versión del proyecto Snapcraft utilizado en el momento de la compilación.

-version-script: git -C parts/cointop/build rev-parse --short HEAD
+adopt-info: cointop
parts:
  cointop:
+    override-pull: |
+      snapcraftctl pull
+      snapcraftctl set-version $(git rev-parse --short HEAD)     

Resumen

La migración a bases más nuevas implica algunos cambios de sintaxis, la inclusión de diferentes versiones de paquetes de etapa y algo de enfoque en las variables de entorno y declaraciones de interfaz. Este artículo cubre solo un subconjunto de posibles escenarios y casos de uso que puede encontrar, pero esperamos que le brinde un empujón en la dirección correcta.

Entendemos que los principales cambios en snapcraft.yaml no son fáciles y queremos que este viaje sea lo más sencillo y práctico posible. Si tiene alguna pregunta, o quizás sugerencias para otros usuarios, puede participar en un hilo existente sobre este tema y proporcione su opinión.

Foto por Tanguy Sauvin en Unsplash.