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

173

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?

Evan
fuente

Respuestas:

87

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.

wzzrd
fuente
99
Para corregirlo en el empaquetado de Debian, el debiandirectorio existe en el directorio en el que se extrajo la fuente ascendente, y Debian valora mucho el concepto de un tarball fuente prístino. Cuando se crea un paquete fuente, hay tres archivos (dos para paquetes nativos) que en conjunto se denominan paquete fuente: el tarball ascendente (preferiblemente prístino, la política de Debian requiere que se vuelvan a empaquetar algunos proyectos), un tarball del directorio debian para el nuevo formato 3.0, (un diferencial para el antiguo formato 1.0) y un .dsc.
Umang
8
El directorio debian no entra en el tarball ascendente, permanece en el .diff.gzo en los .debian.tar.gzarchivos del paquete fuente, aunque el debiandirectorio está dentro del árbol fuente cuando se extrae el paquete fuente. Por cierto: cuando la política no requiere reempaquetado, el MD5 del tarball tiene que coincidir con el tarball aguas arriba. Además, para aclarar, los parches que se convirtieron en el mantenedor de la fuente ascendente se almacenan en el directorio debian (formato fuente 3.0) y en el .diff.gz(formato 1.0).
Umang
Umang, gracias por tu corrección. Eliminaré la parte de alterar el tarball de upstream para asegurarme de que nadie tenga una idea equivocada.
wzzrd
2
Ahora se ve bien, excepto que todavía tiene un "Para RPM es importante usar exactamente el mismo tarball que el que lanza el proyecto aguas arriba, hasta la marca de tiempo". Debido a mi total falta de experiencia con los RPM, no sé si la diferencia en la política es enorme, pero como dije, un desarrollador de Debian insistirá en que sea exacta a la marca de tiempo a menos que el tarball ascendente viole la política de Debian y necesite ser reempaquetado
Umang
77
@wzzrd, en realidad es fácil tener sus archivos fuente juntos en un directorio por paquete, definiendo% _specdir y% _sourcedir en su archivo ~ / .rpmmacros.
mattdm
95

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.

vdboor
fuente
@Tshepang: fijo
vdboor
13
En mi opinión, he despreciado los RPM por la razón exacta que mencionó: "RPM también sufrió de sitios como rpmfind donde encontraría más de 10 paquetes incompatibles para diferentes distribuciones". También me resulta extremadamente difícil encontrar un RPM para el software que necesito. Mientras que para DEB: "Apt ocultó completamente este problema para los paquetes DEB porque todos los paquetes se instalaron desde la misma fuente". que son realmente fáciles de encontrar y usar. Además, DEB siempre parece encontrar e instalar dependencias mejor, mientras que los RPM siempre me dejan colgar ... ¡mi opinión después de 15 años de usar ambos!
Jeach
2
Creo que esta respuesta aborda la pregunta desde el punto de vista del consumidor, a diferencia de @ wzzrd, que está completamente centrada en el desarrollador / empaquetador. Además, muy claro sobre el nivel de separación.
GnP
1
Su texto ha sido copiado a WikiVS , parece atribuirse correctamente.
Martin Ueding
1
Desde la perspectiva del usuario, esta es la mejor respuesta. Y agregaría que usar PPA es mucho más simple que agregar un nuevo repositorio de yum.
Marco Sulla
39

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.

Gilles
fuente
2
Parece que en estos días guarda el nuevo archivo de configuración en *.rpmnewlugar de golpear el modificado, al menos en openSUSE.
Evan
1
Ambos están listos, por lo que obtienes una dispersión de archivos rpmsave y rpmnew.
Burhan Ali
44
Usted es incorrecto acerca de los RPM, no utiliza formatos estándar. RPMS utiliza CPIO para la sección de datos, que es un formato de archivo estándar. Las otras secciones son en su mayoría encabezados. Puede usar la herramienta rpm2cpio para extraer solo la sección de datos del RPM y extraer los archivos contenidos dentro del rpm. Por ejemplo: rpm2cpio foobar.rpm | cpio -idmv
Tuxdude
... y hay rpm2cpio.shpara aquellos inclinados.
Michael Shigorin
El único cambio importante en el debformato que recuerdo fue cuando se data.tar.gzhizo data.tar.xz, momento en el que los antiguos dpkgdejaron de poder abrir nuevos paquetes.
mtraceur
19

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).

Maciej Piechotka
fuente
66
¿No es la "creciente popularidad" básicamente "Ubuntu está basado en Debian, y entonces, ya sabes, ahí tienes?"
mattdm
"dpkg vs yum" es la comparación incorrecta ya que el primero es un administrador de paquetes, pero el segundo no lo es (al igual que apt / aptitude son administradores de nivel de repositorio en lugar de simplemente "paquete").
Michael Shigorin
14

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).

arielf
fuente
Se trata más bien de "redhat vs canonical" (con la cosecha canónica de lo que debian ha estado haciendo durante dos décadas) y no de "rpm vs deb". Lo digo como miembro del equipo ALT Linux.
Michael Shigorin
Sí, precisamente Y bien dicho.
arielf
12

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.

Shawn J. Goff
fuente
8

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.

Luc Stepniewski
fuente
6

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.

johansson
fuente
8
Llamar a los RPM "patentados" es un poco fuerte. Hay algunos encabezados adicionales y tal, pero el núcleo de un RPM es un archivo cpio comprimido con gzip. Hay una herramienta que viene con RPM llamada rpm2cpio que le permite extraer este núcleo para que pueda jugar con él de la misma manera que con un archivo .deb.
Warren Young
44
Basura. Los RPM no son archivos binarios propietarios. Solían construirse alrededor de cpio (que es antiguo, sí, pero no patentado), mientras que las versiones más nuevas de RPM usan xz, que también está disponible como código abierto.
wzzrd
Bien, lo cité, porque, por supuesto, no es verdaderamente propietario y eso es exactamente lo que quiero decir: encabezados adicionales, etc., por lo que no es un archivo ar como un deb. No es un gran problema, solo una cosa menor.
johansson
55
Quizás debería reemplazar los "archivos binarios propietarios" por "archivos de almacenamiento con encabezados no estándar agregados".
Ryan Thompson
Los interesados ​​pueden encontrar rpm2cpio.shguión.
Michael Shigorin
5

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.

descriptor
fuente
En mi humilde opinión, el servicio de compilación de openSUSE es lo mejor que se ha encontrado en mucho tiempo. Realmente lo han hecho bien.
Archie
Aunque se trata de deb vs rpm, tienes razón zypper es increíble con repositorios de soporte con prioridades y el increíble solucionador SAT.
drahnr
5

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).

Mike Gray
fuente
1
Hola @ MikeGray. El enlace está roto. Por favor, ¿podrías actualizarlo?
olibre
4

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.

Texas
fuente
Todas estas cosas también son ciertas para, por ejemplo, RPM empaquetados para Fedora.
mattdm
1
Las herramientas de generación de dependencia de Debian son casi inexistentes, estamos a años luz de ALT Linux (distribución basada en RPM que emplea APT).
Michael Shigorin
4

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.

mtraceur
fuente
Viniendo de un fondo principalmente de Red Hat, esta respuesta es una maravillosa mirada a un mundo nuevo para mí. Ahora estoy usando Ubuntu en casa, así que espero llegar a "tocar el violín" de esta manera. La respuesta sería IMO mejorada con un enlace a un manual sobre algunas de estas "herramientas estándar que existen en la mayoría de los sistemas" a las que alude. ;)
Comodín hace