Pociones en Mageia. 05 – De como Mageia está entre las mejores distros “user-friendly” aunque muchos lo desconocen.

Esta semana, hemos estado cocinando una poción con algunos ingredientes que nos aporta nuestro gran equipo de desarrolladores y empaquetadores. La gestión y empaquetado de las aplicaciones en Mageia frente a otros competidores hace muy fácil la gestión del sistema y el uso del software para nuestros usuarios. La implementación de las herramientas gráficas como el Centro de Control de Mageia forman una parte importante del sistema, pero lo que realmente se desconoce, es cómo se empaquetan algunas aplicaciones con respecto a otros sistemas, cómo se valora la adhesión de plugins y extras de software para las aplicaciones y cómo se gestionan las dependencias de todo durante el empaquetado. Empecemos!

Principios de concepto

Mageia ha heredado y perfeccionado la filosofía de empaquetado de Mandriva/Mandrake, nuestro objetivo está centrado en entregar las aplicaciones “listas para usar”, sin escatimar en funcionalidades opcionales o complementos. Otras distribuciones tienden a empaquetar las aplicaciones en su versión más ligera dejando aparte los plugins o complementos, esto obliga al usuario a buscar paquetes extra. En Mageia incluimos en muchos casos, plugins, integraciones y soporte multimedia directamente en la aplicación o bajo un único metapaquete.

Mageia destaca por una filosofía de empaquetado integrada: en lugar de fragmentar un programa en múltiples subpaquetes o aplicar recortes de licencias estrictos en el repositorio principal, los mantenedores de Mageia compilan el software con el mayor número de extensiones, filtros y soporte de hardware habilitados de serie, siempre que estos aporten un plus de funcionalidad a la aplicación y sea aprobados por el equipo de empaquetado.

Nuestro instalador

Actualmente en Mageia 10 disponemos de URPMI (User RPM Installer) que es nuestro gestor de paquetes por defecto, y la columna vertebral tanto gráfica como por terminal de instalación de aplicaciones, aunque también se incluye soporte nativo para DNF (ahora DNF5).

Urpmi tiene algunas ventajas frente a sus competidores como por ejemplo:

  • Utiliza archivos de síntesis muy ligeros que contienen únicamente los datos indispensables para resolver dependencias, permitiendo consultar o refrescar repositorios de forma casi instantánea, incluso en conexiones lentas.
  • No necesita almacenar localmente la descripción completa e información de cada paquete si no se requiera, ahorrando espacio en disco en los índices.
  • Una de sus mayores ventajas no es solo la línea de comandos, sino que el gestor de paquetes gráfico “rpmdrake”, comparte el mismo motor. En otros gestores, las herramientas gráficas actúan como wrappers independientes que a veces entran en conflicto o no reflejan los mismos estados de paquetes huérfanos.
  • Urpmi lleva décadas perfeccionando su algoritmo de detección de paquetes huérfanos que quedan tras desinstalar una aplicación, adaptándose a la estructura de paquetes RPM de Mageia, esto evita desinstalar librerías críticas del sistema por error durante la limpieza.

En Mageia también se habilitó DNF por algunas características modernas:

  • Historial de transacciones.
  • Módulos y AppStream. Mejor integración con tiendas de software modernas.
  • Soporte upstream activo. Es mantenido directamente por el proyecto rpm.org.

Algunos comandos de urpmi en terminal:

  • urpme: para eliminar paquetes.
  • urpmq: para consultar paquetes.
  • urpmf: para buscar qué paquete contiene determinados archivos o capacidades.
  • urpmi: para instalación y actualización.


Un breve esquema

En Mageia, a través de nuestras secciones de repositorios, se empaquetan versiones de programas compiladas desde el primer día con soporte habilitado para por ejemplo, todos los módulos de red, protocolos de streaming y aceleración de vídeo por hardware, así como múltiples formatos de imagen propietarios o raros que otras distribuciones mueven a repositorios secundarios o directamente eliminan. Se prioriza la comodidad del usuario final sobre la “pureza” estricta del empaquetado, siempre y cuando un complemento haga más útil a la aplicación empaquetada, esto se debe en gran parte a los repositorios oficiales “Tainted” dedicados a software con patentes o restricciones legales en ciertos países, que permiten empaquetar aplicaciones en su versión completa sin restringir funciones.

En Mageia se mantienen, infraestructura de construcción, dependencias, políticas y controles para que los paquetes formen un sistema coherente.

Un ejemplo claro de esto es el paquete “gimp-plugin-astronomy” que permanece disponible para instalar hasta el fin de soporte de Mageia 9, aunque ha dejado de ser mantenido por sus creadores, en Mageia se ha mantenido para nuestros usuarios hasta el lanzamiento de Gimp 3.0 con el cual ya deja de ser compatible por el paso a Python 3.

Algunos otros ejemplos:

  • Libreoffice. En otras distribuciones se empaqueta en componentes divididos y se omiten por ejemplo temas de iconos o integración con bases de datos o entornos de escritorio.
  • Inkscape. En Mageia incluye un mapa de dependencias que activa por defecto todas las extensiones de renderizado matemático, procesamiento de mapas de bits e importación/exportación de archivos CAD sin tener que buscar otras librerías python.
  • Audacity, Vlc, Kodi. A través de los distintos repositorios, se empaquetan con soporte habilitado para características que no aparecen en otras distribuciones.
  • Pidgin. Ya hablamos de esta aplicación en otra poción. El empaquetado de Mageia es muy completo con muchos plugins y protocolos de mensajería que no se encuentran en otras distribuciones.


Visión de empaquetado en Mageia

Detrás del empaquetado, existen unas políticas definidas y procesos de revisión con los que intentamos que el software encaje en el sistema, en lugar de distribuir los paquetes como los publican los desarrolladores.

Algunas funciones destacadas de nuestro empaquetado:

  • Python. Convenciones claras, pyproject, noarch, documentación y dependencias gestionadas por RPM:
  • Java. Evitamos dependencias JAR duplicadas y mantenemos separación de componentes.
  • Firefox. Paquete principal y traducciones independientes. Se instala el idioma requerido en base al idioma del sistema.
  • Libreoffice. Instalación de toda la suite y el idioma requerido en base al idioma del sistema, en un solo metapaquete, o instalación por separado de aplicativos.
  • Bibliotecas. Separación de runtime, desarrollo y dependencias.
  • Aplicaciones KDE/Qt. Políticas específicas para nombres, bibliotecas y componentes.
  • Licencias. Disponemos de separación de licencias mediante repositorios mantenidos “Core/Nonfree/Tainted/.
  • Actualizaciones validadas por el equipo de QA antes de llegar a estable.


¿Qué aporta todo esto al usuario?

La mayoría de estas decisiones no aparecen en una captura de pantalla. No hacen que Plasma tenga mejores animaciones ni que Firefox abra más rápido por sí mismas.

Su valor aparece en situaciones más cotidianas:

  • Instalar una aplicación y obtener automáticamente sus dependencias correctas.
  • Eliminarla sin dejar archivos desperdigados.
  • Actualizar una biblioteca sin tener varias copias incompatibles.
  • Instalar únicamente los idiomas que necesitamos.
  • Instalar documentación sólo cuando nos interesa.
  • Disponer de paquetes de desarrollo separados.
  • Mantener una base de software coherente.
  • Recibir actualizaciones que han pasado por un proceso de validación.

Es decir, nuestros usuarios no tiene que pensar constantemente en el empaquetado. Si el trabajo está bien hecho, simplemente funciona.

Conclusiones

El principal mérito de nuestro empaquetado, está en como se intenta desde todos los equipos, encajar cada programa dentro del conjunto.

Las políticas de empaquetado, la separación de componentes, el tratamiento de las dependencias, el cuidado con las bibliotecas incluidas por terceros, la gestión de licencias y el proceso de control de calidad, forman un sistema integrado y coherente.

El trabajo de nuestros equipos de empaquetado, desarrollo y control de calidad, aunque no es visible para nuestros usuarios o el público general, es una de las partes más importantes de lo que hace que nuestra distribución sea realmente una distribución Linux estable y confiable. Existe una cantidad de trabajo de ingeniería dedicado a que todo encaje para llegar al resultado final.

Esta entrada fue publicada en Sin categoría. Guarda el enlace permanente.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *