¿Cuáles son las ventajas y desventajas de deb vs. rpm?

Por alguna razón, siempre he usado distribuciones basadas en RPM (Fedora, Centos y actualmente openSUSE). A menudo escuché que decía que deb es mejor que rpm, pero cuando se le preguntó por qué, nunca he podido obtener una respuesta coherente (por lo general, recibo un fervor entusiasta y grandes cantidades de saliva).

Entiendo que puede haber algunas razones históricas, pero para las distribuciones modernas que usan los dos métodos de empaque diferentes, ¿alguien puede dar los méritos técnicos (u otros) de uno contra el otro?

La principal diferencia para un mantenedor de paquetes (creo que sería 'desarrollador' en la jerga de Debian) es la forma en que se combinan los metadatos del paquete y los scripts que lo acompañan.

En el mundo de RPM, todos sus paquetes (los RPM que mantiene) se encuentran en algo así ~/rpmbuild. Debajo, está el SPECdirectorio para sus archivos de especificaciones, un SOURCESdirectorio para tarballs de origen RPMSy SRPMSdirectorios para colocar RPM y SRPM recién creados, y algunas otras cosas que ahora no son relevantes.

Todo lo que tiene que ver con cómo se creará el RPM se encuentra en el archivo de especificaciones: qué parches se aplicarán, posibles guiones previos y posteriores, metadatos, registro de cambios, todo. Todos los tarballs de origen y todos los parches de todos sus paquetes están en FUENTES.

Ahora, personalmente, me gusta el hecho de que todo entra en el archivo de especificaciones, y que el archivo de especificaciones es una entidad separada del tarball fuente, pero no estoy demasiado entusiasmado con tener todas las fuentes en FUENTES. En mi humilde opinión, las fuentes se abarrotan bastante rápido y tiendes a perder la noción de lo que hay allí. Sin embargo, las opiniones difieren.

Para los RPM es importante usar exactamente el mismo tarball que el que lanza el proyecto aguas arriba, hasta la marca de tiempo. En general, no hay excepciones a esta regla. Los paquetes de Debian también requieren el mismo tarball que el upstream, aunque la política de Debian requiere que se reenvasen algunos tarballs (gracias, Umang).

Los paquetes de Debian tienen un enfoque diferente. (Perdone cualquier error aquí: tengo mucha menos experiencia con las deb que con las RPM). Los archivos de desarrollo de los paquetes Debian están contenidos en un directorio por paquete.

Lo que (creo) me gusta de este enfoque es el hecho de que todo está contenido en un solo directorio.

En el mundo de Debian, es un poco más aceptado llevar parches en un paquete que (todavía) no está en sentido ascendente. En el mundo de RPM (al menos entre los derivados de Red Hat) esto está mal visto. Consulte "Proyecto Fedora: Mantenerse cerca de proyectos anteriores" .

Además, Debian tiene una gran cantidad de scripts que pueden automatizar una gran parte de la creación de un paquete. Por ejemplo, crear un paquete - simple - de un programa Python configurado con herramientas, es tan simple como crear un par de archivos de metadatos y ejecutarlos debuild. Dicho esto, el archivo de especificaciones para dicho paquete en formato RPM sería bastante corto y, en el mundo RPM, también hay muchas cosas que están automatizadas en estos días.

Mucha gente compara la instalación de software con apt-gety rpm -i, por lo tanto, dice DEB mejor. Sin embargo, esto no tiene nada que ver con el formato de archivo DEB. La comparación real es dpkgvs rpmy aptitude/ apt-*vs zypper/ yum.

Desde el punto de vista del usuario, no hay mucha diferencia en estas herramientas. Los formatos RPM y DEB son archivos de archivo, con algunos metadatos adjuntos. Ambos son igualmente arcanos, tienen rutas de instalación codificadas (¡qué asco!) Y solo difieren en detalles sutiles. Ambos dpkg -iy rpm -ino tienen forma de descubrir cómo instalar dependencias, excepto si se especifican en la línea de comandos.

Además de estas herramientas, hay una gestión de repositorio en forma de apt-...o zypper/ yum. Estas herramientas descargan repositorios, rastrean todos los metadatos y automatizan la descarga de dependencias. La instalación final de cada paquete individual se entrega a las herramientas de bajo nivel.

Durante mucho tiempo, apt-getha sido superior en el procesamiento de la enorme cantidad de metadatos realmente rápido, mientras yumque llevaría años hacerlo. RPM también sufrió sitios como rpmfind donde encontraría más de 10 paquetes incompatibles para diferentes distribuciones. Aptocultó completamente este problema para los paquetes DEB porque todos los paquetes se instalaron desde la misma fuente.

En mi opinión, zypperrealmente ha cerrado la brecha apty no hay razón para avergonzarse de usar una distribución basada en RPM en estos días. Es igual de bueno, si no más fácil de usar, con el servicio de compilación de openSUSE disponible para un gran índice de paquetes compatibles.

Desde el punto de vista del administrador del sistema, he encontrado algunas diferencias menores, principalmente en el conjunto de herramientas dpkg / rpm en lugar del formato del paquete.

• dpkg-divertpermite que su propio archivo desplace al que viene de un paquete. Puede ser un salvavidas cuando tiene un programa que busca un archivo /usro /libno acepta /usr/localuna respuesta. La idea ha sido propuesta, pero por lo que puedo decir no adoptada, en rpm.

• Cuando administré por última vez los sistemas basados ​​en rpm (lo que ciertamente era hace años, tal vez la situación mejoró), rpm siempre sobrescribía los archivos de configuración modificados y movía mis personalizaciones a *.rpmsave(IIRC). Esto ha hecho que mi sistema no se pueda iniciar al menos una vez. Dpkg me pregunta qué hacer, manteniendo mis personalizaciones como predeterminadas.

• Un paquete binario rpm puede declarar dependencias en archivos en lugar de paquetes, lo que permite un control más fino que un paquete deb.

• No puede instalar un paquete de la versión N rpm en un sistema con la versión N-1 de las herramientas rpm. Eso también podría aplicarse a dpkg, excepto que el formato no cambia con tanta frecuencia.

• La base de datos dpkg consta de archivos de texto. La base de datos rpm es binaria. Esto hace que la base de datos dpkg sea fácil de investigar y reparar. Por otro lado, siempre y cuando nada salga mal, las rpm pueden ser mucho más rápidas (instalar un deb requiere leer miles de archivos pequeños).

• Un paquete deb utiliza formatos estándar ( ar, tar, gzip) para que pueda inspeccionar, y en un pellizco pellizco) paquetes deb fácilmente. Los paquetes Rpm no son tan amigables.

RPM:

• 'Estandarizado' (no es que no haya una especificación de deb)
• Usado por muchas distribuciones diferentes (pero los paquetes de uno no necesariamente funcionan en otro)
• IIRC permite dependencias en archivos, no solo en paquetes

DEBUTANTE:

• Creciente popularidad
• Permite recomendaciones y sugerencias (posiblemente RPM más reciente también lo permita)

Probablemente la pregunta más importante es el administrador de paquetes (dpkg vs. yum vs. aptitude, etc.) en lugar del formato del paquete (ya que ambos son comparables).

Como dijeron varios respondedores, no es tanto que cierto formato de paquete sea ​​claramente superior. Técnicamente, pueden ser más o menos comparables. Desde mi perspectiva, muchas de las diferencias, y por qué las personas prefieren una sobre la otra, tienen que ver con:

• La filosofía del diseño del paquete original y el público objetivo.
• El tamaño de la comunidad y, por extensión, la calidad y riqueza de los repositorios.

Filosofía:

En el mundo Ubuntu / Debian / Mint / ..., los usuarios esperan que el paquete instalado "funcione" una vez que esté instalado. Esto significa que durante la instalación, se espera que los paquetes se encarguen de todo lo necesario para que realmente funcionen bien, incluidos, entre otros:

• configurar trabajos cron necesarios u opcionales
• configurar alternativas / alias
• configurar scripts de inicio / apagado
• incluidos todos los archivos de configuración necesarios con valores predeterminados que tienen sentido
• mantener versiones antiguas de bibliotecas y agregar enlaces simbólicos con versiones correctas a bibliotecas (.so's) para compatibilidad con versiones anteriores
• Soporte limpio para binarios de múltiples arcos (32 y 64 bits) en la misma máquina, etc.

En el mundo de las rpm, es cierto que esta era la situación hace varios años, y puede haber mejorado desde entonces, me encontré teniendo que ejecutar pasos adicionales (por ejemplo, chkconfig, habilitar trabajos cron) para que los paquetes realmente funcionen. Esto puede estar bien para los administradores de sistemas o las personas que tienen conocimientos sobre Unix, pero hace que las experiencias de los novatos sufran. Tenga en cuenta que no es que el formato del paquete RPM en sí mismo evite que esto suceda, es solo que muchos paquetes de facto no están "completamente hechos" desde la perspectiva de un novato.

Tamaño de la comunidad, participación y riqueza de repositorios:

Dado que la comunidad ubuntu / debian / mint / ... es más grande, hay más personas involucradas en el empaquetado y prueba de software. Encontré que la riqueza y la calidad de los repositorios son superiores. En ubuntu, rara vez, si es que lo necesito, necesito descargar el código fuente y construir desde él. Cuando cambié de Red Hat a Ubuntu en casa, el repositorio típico de RHEL tenía ~ 3000 paquetes, mientras que al mismo tiempo, ubuntu + universe + multiverse, todos disponibles directamente desde cualquier espejo Canonical, tenía ~ 30,000 paquetes (aproximadamente 10x). La mayoría de los paquetes que buscaba en formato RPM no eran fácilmente accesibles a través de una simple búsqueda y haciendo clic en el administrador de paquetes. Exigieron cambiar a repositorios alternativos, buscar en el sitio web del servicio rpmfind, etc. Esto, en la mayoría de los casos, en lugar de resolver el problema, interrumpió mi instalación al no restringir qué dependencias pueden o no actualizarse correctamente. Llegué al fenómeno del "infierno de la dependencia", como lo describió Shawn J. Goff anteriormente.

En contraste en Ubuntu / Debian, descubrí que casi nunca necesito construir desde la fuente. También por:

• El ciclo de lanzamiento rápido de Ubuntu (6 meses)
• La existencia de PPA totalmente compatibles que funcionan fuera de la caja
• Los repositorios de fuente única (todos alojados por Canonical) no necesitan buscar repositorios alternativos / complementarios
• Experiencia de usuario perfecta desde hacer clic para ejecutar

Nunca tuve que comprometer versiones anteriores de paquetes que me importaban, incluso cuando no fueron mantenidos por desarrolladores oficiales (canónicos). Nunca tuve que abandonar mi amigable administrador de paquetes GUI favorito para realizar una búsqueda conveniente por palabra clave, para encontrar e instalar cualquier paquete que quisiera. Además, algunas veces instalé paquetes debian (no canónicos) en Ubuntu y funcionaron bien, a pesar de que esta compatibilidad no está oficialmente garantizada.

Tenga en cuenta que esto no está destinado a iniciar una guerra de llamas, es solo compartir mi experiencia de haber usado ambos mundos en paralelo durante varios años (trabajo vs hogar).

Creo que el sesgo no proviene del formato del paquete, sino de las inconsistencias que solían existir en los repositorios de RedHat.

Cuando RedHat era una distribución (antes de los días de RHEL, Fedora y Fedora Core), las personas a veces se encontraban en "RPM Hell" o "dependencia Hell". Esto ocurrió cuando un repositorio terminaría con un paquete que tenía dependencias (varias capas de profundidad, generalmente) que eran mutuamente excluyentes. O surgiría cuando dos paquetes diferentes tuvieran dos dependencias mutuamente excluyentes. Este fue un problema con el estado del repositorio, no con el formato del paquete. El "Infierno de RPM" dejó un disgusto por los sistemas RPM entre una población de usuarios de Linux que se habían quemado por el problema.

También existe la diferencia "filosófica" en la que en los paquetes Debian puede hacer preguntas y, de este modo, bloquear el proceso de instalación. El lado negativo de esto es que algunos paquetes bloquearán sus actualizaciones hasta que responda. El lado bueno de esto es, también como una diferencia filosófica, en los sistemas basados ​​en Debian, cuando se instala un paquete, se configura (no siempre como lo desea) y se ejecuta. No en los sistemas basados ​​en Redhat donde necesita crear / copiar desde / usr / share / doc / * un archivo de configuración predeterminado / plantilla.

Una cosa que me gusta de los RPM es la adición (¿reciente?) De RPM delta. Esto permite una actualización más fácil, reduciendo el ancho de banda requerido.

Los DEB son archivos ar estándar (con más archivos estándar dentro), los RPM son archivos binarios "propietarios". Personalmente, creo que lo primero es más conveniente.

Solo dos cosas que puedo pensar fuera de mi cabeza. Ambos son muy comparables. Ambos tienen excelentes herramientas para el embalaje. No creo que haya tantos méritos para uno sobre el otro o viceversa.

OpenSUSE Build Service (OBS) y zypper son algunas de las razones por las que prefiero RPM sobre deb desde el punto de vista del empaquetador y del usuario. Zypper ha recorrido un largo camino y es bastante rápido. OBS, aunque puede manejar debs, es realmente bueno cuando se trata de empaquetar rpm para varias plataformas como openSUSE, SLE, RHEL, centos, fedora, mandriva, etc.

Los paquetes Debian pueden incluir un tamaño instalado , pero no creo que los RPM tengan un campo equivalente. Se puede calcular en función de los archivos incluidos en el paquete, pero tampoco se puede confiar en él debido a las acciones que se pueden tomar en los scripts de pre / post instalación.

Aquí hay una referencia bastante buena para comparar algunas características específicas que están disponibles para cada formato de empaque específico: http://debian-br.sourceforge.net/txt/alien.htm (según el servidor web, ese documento es bastante antiguo : Última modificación: dom, 15 de octubre de 2000, por lo que esta podría no ser la mejor referencia).

Para los paquetes Debian hay un gran conjunto de scripts de ayuda, un manual de políticas coherente y al menos una forma de hacer casi todo. Las dependencias se manejan muy bien y se pueden definir con muy buena granularidad. Reconstruir paquetes es muy fácil con los paquetes de Debian y está bien respaldado por las herramientas disponibles.

Ninguna de las otras respuestas toca cómo las siguientes tres diferencias fundamentales tienen consecuencias reales:

1. deblos archivos son básicamente ararchivos que contienen dos tarballs comprimidos
2. deblos paquetes y el dpkgsistema almacenan sus scripts de mantenedor como archivos separados
3. dpkgy rpmejecute los scripts de mantenedor en un orden diferente durante las actualizaciones.

En conjunto, estas diferencias han hecho que sea mucho más fácil para mí Para solucionar los problemas causados por los malos paquetes, ya que los paquetes se comportan de la forma en que los necesito a, en debsistemas basados en que en rpmlos sistemas basados, tanto como administrador del sistema y como un empaquetador .

Debido al n. ° 1, si necesito cambiar un debarchivo, puedo abrirlo trivialmente, hacer los cambios que quiera y volver a empaquetarlo, utilizando herramientas estándar que existen en la mayoría de los sistemas .

Esto incluye cambiar / agregar / eliminar cualquier dependencia, o cualquiera de los archivos del paquete, o cualquiera de las secuencias de comandos del mantenedor, o cambiar la versión o el nombre del paquete.

Debido al n. ° 2, si hay un problema en las secuencias de comandos "eliminar" instaladas por un paquete que ya está instalado , puedo solucionarlo trivialmente, utilizando herramientas estándar que existen en cualquier sistema .

Debido al n. ° 3, puedo hacer algunas de esas soluciones simplemente lanzando una nueva versión de mi paquete, porque durante la actualización, dpkgejecuta el script "preinstalado" de la nueva versión del paquete antes del script "post-remove" de La versión anterior.

Esto significa que el área de superficie para violar el "principio de recuperabilidad" es menor en los debpaquetes: se pueden recuperar más errores en una versión anterior del paquete con una nueva versión.

Y dado que modificar el paquete es muy fácil: la carga de violín y la sobrecarga de conocimiento específicos del paquete es pequeña, es accesible para más personas y requiere menos tiempo y esfuerzo con los debarchivos.