it-swarm-es.tech

¿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?

173
Evan

La principal diferencia para un mantenedor de paquetes (creo que sería 'desarrollador' en la jerga de Debian) es la forma en que se juntan 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 como ~/rpmbuild. Debajo, está el directorio SPEC para sus archivos de especificaciones, un directorio SOURCES para tarballs de origen, RPMS y SRPMS directorios para colocar RPM recién creados y SRPM en, y algunas otras cosas que no son relevantes ahora.

Todo que tiene que ver con cómo se creará el RPM está en el archivo de especificaciones: qué parches se aplicarán, posibles pre y post-scripts , 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 por tener todas 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 el exacto 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. Ver "FedoraProject: Mantenerse cerca de proyectos aguas arriba" .

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 setuptool'ed Python, es tan simple como crear un par de archivos de metadatos y ejecutar debuild. Dicho esto, el archivo de especificaciones para dicho paquete en formato RPM sería bastante corto y también en el mundo RPM, hay muchas cosas que están automatizadas en estos días.

87
wzzrd

Mucha gente compara la instalación de software con apt-get a rpm -i, y por lo tanto decir DEB mejor. Sin embargo, esto no tiene nada que ver con el formato de archivo DEB. La comparación real es dpkg vs rpm y 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 -i y rpm -i no tiene forma de averiguar 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.

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

En mi opinión, zypper realmente ha cerrado la brecha con apt y 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 openSUSE disponible para obtener un enorme índice de paquetes compatibles.

97
vdboor

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-divert hace posible que su propio archivo desplace al que viene de un paquete. Puede ser un salvavidas cuando tiene un programa que busca un archivo en /usr o /lib y no tomaré /usr/local para una 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 cual es cierto que fue 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 apuro Tweak) los 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).

19
Maciej Piechotka

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 tengan 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 son de facto no "completamente hecho" de 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ó anteriormente Shawn J. Goff.

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 de forma inmediata
  • 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 tiene la intención de comenzar una guerra de llamas, es solo compartir mi experiencia de haber usado ambos mundos en paralelo durante varios años (trabajo vs hogar).

15
arielf

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.

12
Shawn J. Goff

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.

8
Luc Stepniewski

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.

6
johansson

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 instalación previa/posterior.

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 la web servidor, 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).

5
Mike Gray

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 agradable cuando se trata de empaquetar rpm para varias plataformas como openSUSE, SLE, RHEL, centos, Fedora, mandriva, etc.

5
decriptor

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

  1. Los archivos deb son ​​básicamente archivos ar que contienen dos tarballs comprimidos
  2. Los paquetes deb y el sistema dpkg almacenan sus scripts de mantenedor como archivos separados
  3. dpkg y rpm ejecutan los scripts del mantenedor en un orden diferente durante las actualizaciones.

En conjunto, estas diferencias han hecho que sea mucho más fácil para mí solucionar problemas causados ​​por paquetes defectuosos y hacer que los paquetes se comporten de la manera que los necesito, en Sistemas basados ​​en deb que en sistemas basados ​​en rpm, ambos como administrador del sistema y como empaquetador.

Debido al n. ° 1, si necesito cambiar un archivo deb, puedo abrirlo trivialmente, hacer los cambios que quiera y volver a empaquetarlo usando las 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, usando herramientas estándar que existen en cualquier sistema .

Debido al # 3, puedo hacer algunas de esas correcciones simplemente lanzando una nueva versión de mi paquete, porque durante la actualización, dpkg ejecuta 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 por violar el "principio de recuperabilidad" es menor en los paquetes deb: 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 archivos deb.

4
mtraceur

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.

4
tex

Ir a buscar en Google

  1. paquetes duplicados rpm
  2. paquetes duplicados dpkg

Lee las páginas que regresan. Es muy revelador que puede tener una base de datos RPM desordenada con paquetes duplicados, mientras que no ocurre tal caso con dpkg.

2
user2472