Solución:
Mucha gente compara la instalación de software con apt-get para rpm -i, y por lo tanto decir mejor DEB. Sin embargo, esto no tiene nada que ver con el formato de archivo DEB. La verdadera comparación 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 solo archivos de almacenamiento, 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 tengo forma de averiguar cómo instalar dependencias, excepto si se especifican en la línea de comando.
Además de estas herramientas, existe la gestión de repositorios 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 muy rápido mientras yum tomaría años hacerlo. RPM también sufrió de 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 a apt y no hay razón para avergonzarse de utilizar 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 índice de paquetes compatibles enorme.
La principal diferencia para un mantenedor de paquetes (creo que sería ‘desarrollador’ en la jerga de Debian) es la forma en que los metadatos del paquete y los scripts que lo acompañan se unen.
En el mundo de RPM, todos sus paquetes (los RPM que mantiene) están ubicados en algo como ~/rpmbuild. Debajo, está el SPEC directorio para sus archivos de especificaciones, un SOURCES directorio para tarballs de origen, RPMS y SRPMS directorios para colocar RPM y SRPM recién creados, y algunas otras cosas que no son relevantes ahora.
Todo eso 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 archivos comprimidos de origen y todos los parches de todos tus paquetes están en FUENTES.
Ahora, personalmente, me gusta el hecho de que todo va en el archivo de especificaciones, y que el archivo de especificaciones es una entidad separada del tarball de origen, pero no estoy demasiado entusiasmado con tener todos fuentes en FUENTES. En mi humilde opinión, las FUENTES se abarrotan bastante rápido y tiendes a perder la pista de lo que hay allí. Sin embargo, las opiniones difieren.
Para las RPM, es importante utilizar el exacto el mismo tarball que el que publica el proyecto upstream, hasta la marca de tiempo. Generalmente, 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 vuelvan a empaquetar algunos tarballs (gracias, Umang).
Los paquetes Debian adoptan un enfoque diferente. (Perdone cualquier error aquí: tengo mucha menos experiencia con deb que con 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 Debian, es un poco más aceptado llevar parches en un paquete que (todavía) no está actualizado. En el mundo de RPM (al menos entre los derivados de Red Hat) esto está mal visto. Consulte “FedoraProject: mantenerse cerca de los 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 con setuptool’ed, 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 en el mundo de RPM, también, hay muchas cosas que están automatizadas en estos días.
Desde el punto de vista de un administrador del sistema, he encontrado algunas diferencias menores, principalmente en el conjunto de herramientas dpkg / rpm en lugar del formato del paquete.
-
dpkg-diverthace 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/usro/liby no tomaré/usr/localpor una respuesta. La idea ha sido propuesta, pero que yo sepa no adoptada, en rpm. -
La última vez que administré sistemas basados en rpm (lo que ciertamente fue hace años, tal vez la situación haya mejorado), 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 pueda arrancar al menos una vez. Dpkg me pregunta qué hacer, manteniendo mis personalizaciones como predeterminadas. -
Un paquete binario rpm puede declarar dependencias de archivos en lugar de paquetes, lo que permite un control más preciso que un paquete deb.
-
No puede instalar un paquete rpm versión N 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 que nada salga mal, rpm puede ser mucho más rápido (instalar un deb requiere leer miles de archivos pequeños).
-
Un paquete deb usa formatos estándar (
ar,tar,gzip) para que pueda inspeccionar y, en caso de necesidad, modificar) los paquetes deb fácilmente. Los paquetes de rpm no son tan amigables.