¿Por qué los desarrolladores de Linux no pueden crear un formato de empaque universal?

Las selecciones de formato de paquete binario del proveedor parecen estar determinadas por una forma de la Ley de Murphy: todas las distribuciones que no usa tienen paquetes. (Corralary: no existe una distribución que satisfaga las dependencias de distribución de su pila de software).

¿Es una cuestión de política, o algo más profundo, que no hemos visto la aparición de un formato de paquete "construir una vez, ejecutar en cualquier lugar"?

Parece apropiado citar a Joel Spolsky en este caso:

(Por cierto, para aquellos de ustedes que siguen el mundo arcano pero políticamente cargado de formatos de alimentación de sindicación de blogs, pueden ver que sucede lo mismo allí. RSS se fragmentó con varias versiones diferentes, especificaciones inexactas y mucha lucha política, y el intento de limpiar todo creando otro formato llamado Atom ha dado como resultado varias versiones diferentes de RSS más una versión de Atom, especificaciones inexactas y mucha lucha política. Cuando intentas unificar dos fuerzas opuestas creando una tercera alternativa, terminas con tres fuerzas opuestas. No has unificado nada y realmente no has arreglado nada.)

(énfasis añadido)

Tiene (al menos) dos sistemas de empaquetado para Linux. Eso es realmente algo bueno. Un solo sistema simplemente creará un tercer sistema.

Hay muchas razones para esto, y un poco de historia es para poner las cosas en perspectiva.

Recuerde que cuando hablamos de "Linux" a lo que generalmente nos referimos es a una de las muchas distribuciones de Linux diferentes . "Linux" es en realidad solo un núcleo del sistema operativo.

El objetivo original de Linux era crear un sistema basado en Unix que se ejecute en PC (inicialmente el 386). El primer paso fue crear el núcleo en sí. Mientras Linus Torvalds estaba trabajando en el núcleo, Richard Stallman estaba trabajando en su propio sistema Free Unix, bajo el proyecto GNU (GNU's Not Unix) . Para abreviar una larga historia, los dos convergieron un poco porque GNU tenía las utilidades asociadas (compilador C / biblioteca / herramientas de compilación, shell, editores de texto, etc.) pero no tenía un núcleo para ejecutarlo, y Linux tenía el núcleo pero no tenía utilidades para ejecutar encima de él para que sea útil para las masas.

Esta convergencia llegó a conocerse oficialmente como GNU / Linux. Verá que muchas distribuciones todavía se refieren a sí mismas como distribuciones GNU / Linux.

Debido a la naturaleza libre y abierta de GNU / Linux, cualquiera podría recogerlo y crear un sistema integrado para sus gustos específicos. El resultado fue que se utilizaron muchos flujos diferentes de diferentes métodos de configuración para crear estos sistemas, lo que tuvo el efecto secundario de crear casi tantos sistemas de administración de paquetes diferentes para adaptarse a cada uno.

Cada sistema completo diferente tenía sus propios seguidores fuertes que se mantuvieron con ellos a lo largo de los años, dando como resultado lo que tenemos hoy: un puñado de sistemas de administración de paquetes ampliamente utilizados, profundamente enraizados y estables como RPM , APT / dpkg y Gentoo's Portage .

Hay proyectos, como Autopackage , que intentan resolver el problema, pero la evolución continua de los diversos sistemas de gestión de paquetes admitidos significa que hay muchos objetivos en movimiento a seguir.

Lo que algunos proveedores de software terminan haciendo es agrupar los binarios específicos y las copias de las dependencias que requieren en un gran paquete que funcionará en sistemas específicos.

Tener el mismo formato de paquete no ayudaría de todos modos. Simplemente no puede usar el mismo paquete en otras distribuciones. A menudo ni siquiera puede usarlo en la versión diferente de la misma distribución. E incluso construir el paquete puede tener los mismos problemas.

Para instalar un paquete, debe cumplir con las dependencias que se forman durante la construcción del paquete. Para compilar un paquete, debe cumplir con las dependencias de compilación. Y estas cosas cambian. Para poder implementar los cambios, es más fácil admitir solo los paquetes que puede modificar para que funcionen después de los cambios.

Si todas las dependencias fueran iguales, no sería una distribución diferente o una versión diferente de la misma distribución.

Creo que hay un poco de "Síndrome no inventado aquí". El sistema de empaquetado de Debian es anterior a RedHat y, sin embargo, es superior en muchos aspectos, pero nunca verá el cambio de RedHat. En cambio, ve a mucha gente usando "apt-rpm" que intenta darle algunas de las ventajas de apt con archivos rpm.

Solo ve por .deb :-)

Hubo varios formatos tentativos, como instalación cero y autoempaquetado . Lamentablemente, ninguno ganó tracción.

Creo que Cletus, Wayne e Iny respondieron esto bastante bien. Me gustaría agregar eso realmente, no es un gran problema. Trabajo en un entorno mixto donde tenemos Gentoo (portage), SUSE (rpm / zypper) y OpenBSD (paquetes y puertos). Instalar paquetes en cualquiera de ellos no es difícil, y realmente no me importa qué formato estén usando.

Desde la perspectiva del software de empaquetado, tampoco es demasiado difícil. Ya sea Gentoo, una distribución basada en RPM o una distribución basada en deb, realmente se reduce a tener recetas para construir el software y agregar algunos metadatos. Siempre que el sistema de compilación de lo que está tratando de empaquetar no sea totalmente una locura, generalmente se necesita poco más que escribir un script de shell glorificado para crear un paquete.

Bueno, siempre hay binarios compilados estáticamente en bolas de alquitrán ... ;-)

No existe una definición de una interfaz binaria estándar para "Linux", ya que es solo un núcleo. Lo más probable es que su pila de software necesite interactuar con algo más que su núcleo, presentando un desafío particular de mantener un ABI estándar entre cientos de árboles de origen dispares.

Sobre el tema de buenas herramientas de empaque, prefiero Debian GNU / Linux por su excelente formato de empaque binario. Ha cubierto el 90% de mis necesidades de herramientas y aplicaciones estándar. El 10% restante se genera a partir de la fuente debido a la inclusión de componentes no libres o dependencias de biblioteca compartida con errores. Cuando esas aplicaciones deben implementarse, construyo binarios personalizados para los clústeres de producción.

Para obtener una compilación única, ejecute el formato de paquete en cualquier lugar sin obligar a todos a usar la misma distribución que necesita un par de características importantes:

• Nombre de paquete globalmente único, de modo que dos personas / distribuciones no pueden crear independientemente paquetes diferentes con el mismo nombre.

• La capacidad de instalar en paralelo diferentes versiones de bibliotecas cuando los paquetes tienen requisitos conflictivos. Una distribución puede decidir qué versión de cada biblioteca usar y forzar a todos los paquetes a usar esa versión. Un sistema que funciona en todas las distribuciones debe ser más flexible.

Zero Install ofrece ambas características:

• Los nombres son URI (por ejemplo, http://rox.sourceforge.net/2005/interfaces/ROX-Filer ). Solo el propietario de un dominio puede crear paquetes dentro de ese espacio de nombres de forma predeterminada.

• Cada versión de cada paquete va en su propio directorio. Cada aplicación ve solo las bibliotecas que necesita, con las versiones con las que es compatible.

Por ejemplo, la aplicación Editar depende de Python <3 como este:

<command name="run" path="Edit/AppRun">
  <runner interface="http://repo.roscidus.com/python/python">
    <version before="3"/>
  </runner>
</command>

Ver también: http://www.osnews.com/story/16956/Decentralised-Installation-Systems

[Nota: soy un desarrollador de instalación 0]