Michael Catanzaro (desarrollador de Epiphany y colaborador en los proyectos GNOME y Fedora), ha planteado una propuesta que podrĂa cambiar la forma en que Fedora Workstation gestiona los paquetes Flatpak.
Y es que en su propuesta, plantea el priorizar FlatHub como fuente predeterminada para los paquetes instalados por los usuarios, limitando el repositorio Flatpak de Fedora a aquellos paquetes que vienen preinstalados en la distribuciĂłn.
El debate sobre la gestiĂłn de Flatpak en Fedora Workstation
En la actualidad, Fedora utiliza su propio repositorio Flatpak como configuración predeterminada. Este repositorio se genera mediante la reconstrucción de paquetes RPM y tiene una prioridad superior respecto a FlatHub. Si bien es posible habilitar la descarga desde FlatHub tras la instalación del sistema, ello requiere que el usuario active manualmente la opción de «repositorios de terceros» en el gestor de software de GNOME. No obstante, incluso con esa configuración habilitada, los paquetes de Fedora siguen teniendo preferencia.
Michael sostiene que la mayorĂa de los usuarios preferirĂan obtener sus paquetes directamente desde FlatHub. Esta plataforma reĂşne paquetes creados y mantenidos por los propios desarrolladores de las aplicaciones, lo cual garantiza un mejor conocimiento de sus particularidades, mayor estabilidad y pruebas más exhaustivas. SegĂşn datos citados por Catanzaro, el 80% de los panelistas consultados expresĂł su preferencia por FlatHub frente al repositorio de Fedora.
Esta situación también ha generado confusión entre los usuarios, quienes asumen que al instalar una aplicación Flatpak en Fedora lo hacen desde FlatHub, como ocurre en otras distribuciones. Sin embargo, los paquetes provienen del repositorio interno de Fedora, con posibles diferencias notables en calidad.
La Fedora Workstation del futuro debe ser:
Seguro y basado en imágenes por defecto: un sistema operativo atĂłmico compuesto por RPMs basados en bootc. La mayorĂa de los usuarios deberĂan optar por el modo basado en imágenes, ya que es mucho más difĂcil dañar el sistema operativo y más fácil de solucionar cuando algo falla.
Flexible si asà lo desea: la conversión del sistema operativo basado en imágenes al sistema operativo tradicional basado en paquetes, administrado por RPM y dnf, debe estar permitida para los usuarios que lo prefieran o lo requieran. O, alternativamente, si la conversión no es posible, la instalación de un Fedora tradicional no atómico debe seguir siendo posible. En cualquier caso, no debemos obligar a los usuarios a usar escritorios basados en imágenes si no lo desean, asà que no hay de qué preocuparse. Pero los escritorios basados en imágenes deben convertirse eventualmente en la opción predeterminada.
Silverblue aĂşn no está listo, pero Fedora tiene una gran comunidad de desarrolladores y deberĂa poder resolver eventualmente los problemas restantes.
Cuando surgen errores, las quejas suelen dirigirse a los desarrolladores oficiales de las aplicaciones, generando tensiones innecesarias, como sucedió en el caso de OBS Studio, cuyo paquete problemático en Fedora tuvo más prioridad que su versión en FlatHub.
Uno de los argumentos a favor de mantener el repositorio personalizado de Fedora es la seguridad: los paquetes se construyen en entornos controlados, a partir del cĂłdigo fuente declarado, y respetan Ăşnicamente licencias abiertas aprobadas por Fedora. Además, es posible incluir parches especĂficos que aĂşn no forman parte del cĂłdigo fuente de los proyectos originales.
Sin embargo, Catanzaro reconoce la necesidad de reforzar la seguridad también en FlatHub. La propuesta incluye trabajar conjuntamente para permitir la construcción de paquetes en infraestructuras verificables, incorporar compilaciones reproducibles y combatir la presencia de runtimes obsoletos. Actualmente, casi un tercio de los paquetes verificados en FlatHub utilizan runtimes cuyo soporte ya ha expirado, lo que representa un riesgo de seguridad.
También se detectaron otros problemas, como dependencias desactualizadas y la desactivación de medidas de aislamiento por parte de algunos desarrolladores, lo que compromete la eficacia del sandboxing. Como solución, se plantea implementar verificaciones automáticas de los runtimes, reforzar las medidas de aislamiento y garantizar un mantenimiento continuo de los paquetes Flatpak.
La transiciĂłn hacia el uso de FlatHub no se plantea de forma abrupta. La idea es permitir que Fedora Workstation, en su ediciĂłn atĂłmica, facilite la instalaciĂłn predeterminada de software libre desde FlatHub, manteniendo los paquetes preinstalados desde el repositorio de Fedora. La modificaciĂłn solo afectarĂa a los paquetes que los usuarios decidan instalar posteriormente mediante el gestor de software de GNOME.
TimothĂ©e Ravier, otro desarrollador de Fedora, ha respaldado esta lĂnea de pensamiento con una propuesta paralela para Fedora 43. En ella, se permitirĂa que algunas aplicaciones seleccionadas y verificadas de FlatHub estĂ©n disponibles para instalaciĂłn directa, mientras que los paquetes preinstalados seguirĂan gestionándose desde Fedora. Este cambio reducirĂa la carga de trabajo de los mantenedores, eliminarĂa la confusiĂłn de los usuarios y contribuirĂa a una mejor colaboraciĂłn entre Fedora y los proyectos principales.
Finalmente, si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.