Fedora 27 llegó con una edición tan singular como novedosa, Modular Server, que fue publicada como beta cuando se produjo el lanzamiento de la última versión de la distribución comunitaria de Red Hat.

Sin embargo, la acogida que tuvo Modular Server no fue ni mucho menos buena, ya que, según el blog oficial de la comunidad de Fedora, los desarrolladores del sistema fueron informados de que Fedora 27 Modular Server tenía “varios problemas de diseño”. Lo más preguntado por los usuarios fue el cómo instalar un paquete determinado, el cual podía ir desde el paquete screen hasta complejas aplicaciones de terceros. “Para hacer que el software esté disponible en un sistema totalmente modular, sus paquetes deben ser parte de un módulo”, algo que no se consiguió en muchos casos.

“La falta de módulos fue un síntoma de un problema más grande con la implicación del empaquetador”, algo que se vio en los desacuerdos que hubo en torno a la implementación y el diseño, además de complicaciones en la curva de aprendizaje. A pesar de que el equipo de Modular Server publicó mucha documentación, el proceso resultaba demasiado complicado para los empaquetadores.

Pero esto no es todo, ya que la misma comunidad de Fedora ha reconocido no haber tenido “un plan sólido sobre cómo manejar las actualizaciones de las implementaciones tradicionales de los paquetes”. Esta situación complicaba tareas como la carga de software de terceros, algo a lo cual se le unió la carencia de algún módulo de “arranque”. Ante la acumulación de despropósitos, la comunidad de Fedora decidió resucitar la edición Server estándar como “plan de contingencia”.

Tras pasar la tormenta, los encargados de Fedora tomaron la decisión de volver a diseñar la edición Modular Server para que sea más comprensible para los usuarios y los empaquetadores. Como solución, se ha optado por tratar el repositorio “para todo” como una “‘plataforma modular’, aunque la herramienta no reportará este contenido como un módulo”. Esto quiere decir que “los creadores de módulos no necesitarán ir más a través de un doloroso proceso de rastrear qué módulos proporcionan la dependencia que necesitan. En su lugar, serán capaces de depender de la versión del sistema disponible en el repositorio ‘para todo’.”

Estas modificaciones tendrían que traer en teoría algunas ventajas, como la posibilidad de “actualizar fácilmente desde una implementación tradicional” gracias a que se “mantienen los repositorios tradicionales como un conjunto de módulos por defecto”, lo que significa que se podría actualizar desde un sistema modular Fedora 27 a Fedora 28 sin pasos especiales. Esto trae una consecuencia colateral, y es que el enfoque modular ya no será exclusivo de la edición para servidores.

Pero no solo en lo que se refiere a la implementación tiene que mejorar Fedora Modular Server, por eso los encargados de su desarrollo suministrarán una serie de herramientas para automatizar la creación de los módulos. Debido a que “la mayoría de los módulos ahora solo requerirán que un único paquete esté en la lista de componentes”, los desarrolladores de Fedora esperan “habilitar el soporte para construir automáticamente una sola rama en dist-git para todas las versiones activas de Fedora y EPEL”. La meta es conseguir que, incluso para los módulos multipaquetes complejos, haya unas definiciones de módulo creadas automáticamente para ofrecer un “punto de partida fácil y obvio.”

De cara a los usuarios finales, lo único que cambiará es que se ofrecerá un repositorio adicional que se añadirá a los de fedora, updates y updates-testing y se encargará de suministrar los “módulos alternativos y suplementarios”, por lo que en caso de no querer que sus paquetes estén disponibles, lo único que tendría que hacer el usuario sería inhabilitarlo de forma estándar, manteniendo el sistema operativo Fedora desde una perspectiva “tradicional”. Por otro lado, la gestión de los módulos se seguirá haciendo mediante DNF.