Las diferencias en la administración de paquetes entre Debian y Arch

Utilizo arch regularmente desde hace unas semanas y no soy un experto en el tema, por lo que esta respuesta no es exhaustiva, solo algunos puntos que he señalado sobre la «flexibilidad / poder»:

• Esto es solo una impresión, pero pacman parece más moderno y simple en su diseño / arquitectura. Al menos hay muchas menos herramientas con las que lidiar. Aunque no conozco el código fuente de apt, simplemente miré el código libalpm (la biblioteca subyacente de pacman) para hacer un parche muy simple, y parece limpio y fácil de entender.

• También es muy rápido (debido a la optimización y probablemente también por preocuparse por algunas cosas (ver más abajo)). La última versión (pacman 3.5, hace unos días) trató de mejorar el rendimiento reduciendo el número de archivos de base de datos involucrados.

• Si bien arch está orientado hacia el uso de paquetes binarios, también tiene ventajas al construir paquetes desde la fuente, con un sistema de construcción similar a los puertos de BSD ( ABS).

• Es muy fácil y rápido crear paquetes, solo unas pocas líneas en un archivo PKGBUILD y listo, no es necesario lidiar con control / reglas / derechos de autor / changelog / lo que sea con los paquetes Debian. Y con unos pocos clics en una interfaz de usuario web, su paquete se comparte con todos en AUR (Arch User Repository).

Cosas que obtengo en Debian y no en arch:

• Triggers / h ooks (lo que hace que apt actualice el caché de iconos, el mandb o lo que sea con solo mirar dónde se instalan los archivos del paquete, sin necesidad de que el empaquetador haga nada) (parece que hay planes para implementar esto).

• debconf (no es gran cosa y, por cierto, al obligarme a hacer las cosas manualmente me obliga a saber qué se hace exactamente) y manejo adecuado de los nuevos archivos de configuración (al menos me gustaría que pacman supiera cuando un archivo de configuración en una nueva versión del paquete es diferente del instalado porque se cambió en la nueva versión o porque lo modifiqué localmente).

• firma de paquetes (parece que se está trabajando ).

Para que arch sea liviano, la única razón real es que viene con pocos paquetes instalados de forma predeterminada y se le anima a agregar lo que necesita, por lo que probablemente no instalar dependencias opcionales de forma predeterminada incita a los usuarios a instalar para evitar la hinchazón .

Comentarios

• No puedo ‘ t analizar esto: pero puedo prescindir de él y, por cierto, sé lo que hago mejor . También hay un error tipográfico en la última oración.
• ¿En qué idioma está escrito el administrador de paquetes pacman? ¿Tiene una funcionalidad de gestión de paquetes de bajo y alto nivel similar a dpkg / apt? Si es así, ¿cómo se llaman?
• @Tshepang: lo siento, aquí no habla inglés nativo. Quise decir » esto no es un gran problema para mí no tener esta funcionalidad (debconf) y al obligarme a hacer las cosas manualmente me obliga a saber qué se hace exactamente «.
• @Faheem Mitha: Pacman está escrito en C y es una interfaz de libalpm, que maneja tanto » alto -level » y » gestión de paquetes » de bajo nivel.
• @zanko: Yo ‘ tampoco soy hablante nativo. Todo lo que quería que hicieras es aclarar la oración, y no en un comentario, sino en la publicación. Por cierto, el error tipográfico que mencioné es opcional . Podría editar la publicación yo mismo, pero pensé que también podrías arreglarlo junto con la parte aclaratoria.

Comencé mi viaje en Linux con Ubuntu lucid y actualmente uso Arch.He escrito un puñado de paquetes Arch, y diré que es mucho más fácil que escribir paquetes Debian. Pero, me gustaría señalar a @gentledevil que Arch tiene un sistema de enlaces para paquetes, conocido como install file.

Básicamente, se llama ${pkgname}.install, y contiene algunas funciones para pre / post instalación / eliminación / actualización; solo coloque sus actualizaciones de caché de fuentes en eso y así sucesivamente y funciona casi igual que los ganchos de Debian.

Además, noté que mencionaste «anclar» una aplicación usando herramientas de administración de paquetes de Debian; Arch «s pacman tiene eso incorporado Además, /etc/pacman.conf acepta una serie de configuraciones, incluida IgnorePkg =, que evitará las actualizaciones de los paquetes enumerados después de equals (espacio delimitado )

Comentarios

• Además, aunque no es un paquete de repositorio, puede usar el contenedor powerpill para que pacman tenga descargas paralelas de varios paquetes, así que en lugar de pacman -S libfoo libbar libbaz descargar cada paquete uno después del otro r, en su lugar, descargaría los tres simultáneamente, aumentando enormemente las velocidades de actualización para obtener mejores conexiones.

Antes de vaya demasiado lejos, estudie la línea de tiempo pictórica de Linux

Para comprender las diferencias en los administradores de paquetes, debe comprender las filosofías del sistema operativo » se muestra arriba

Tres padres principales

1. Redhat, Now Fedora – Administrador de paquetes – RPM, abreviatura de Administrador de paquetes Redhat, línea de comando rpm
2. Slackware – Administrador de paquetes – tgz, archivos comprimidos normales. Aunque estos son solo archivos comprimidos, fueron creados por Slackware upstream y colocados en un repositorio, a veces denominado puerto
3. Debian – DEB, abreviatura de Debian, su herramienta de línea de comandos es Aptitude or Apt

Estos padres son madres y padres de la mayoría de las distribuciones que conocemos hoy. La idea / concepto de un sistema de gestión de paquetes se derivó o compartió en algunos De cualquier forma, todos estos padres son distribuidores binarios, lo que significa que un programa es empaquetado y decidido por un tercero, luego almacenado en un repositorio y consumido o instalado por la base de usuarios.

3 Padres menores

1. Linux From Scratch – Basado en código fuente, sin administrador de paquetes.
2. Gentoo – Derivado de Linux from Scratch . Esta distribución es esencialmente Linux desde cero más un administrador de paquetes, llamado Portage / emerge
3. SourceMage – Conjuro del administrador de paquetes

Estos padres son menores porque su base de usuariosintercambia velocidad y facilidad de instalación con potencia y facilidad de configuración. Cada paquete se descarga y compila desde cero, utilizando variables y archivos de configuración.

The Bridge

Arch fue creado como un puente entre una distribución binaria, como uno de los 3 principales padres, y una distribución basada en fuentes como uno de los 3 padres menores. Como tal, recibe el estado de padre en la línea de tiempo, porque ningún otro padre proporcionó esta funcionalidad. Pacman tiene la flexibilidad de permitir que un usuario instale un paquete binario desde un repositorio oficial o un paquete personalizado utilizando Arch Build System. Este concepto proporciona un equilibrio entre el poder que dan los padres menores con la facilidad de instalación que dan los padres mayores.

En mi opinión, no es el administrador de paquetes el que muestra el poder de un sistema, ya que todos los administradores de paquetes hacen la misma tarea, que es administrar y mantener un sistema saludable. Como tal, el sistema que use debe estar determinado por factores tales como:

• Nivel de usuario: alguien Los nuevos en Linux deben comenzar con un padre principal, mientras que alguien técnicamente competente encontrará un equilibrio.
• Lo que quiere hacer con su sistema: ejecutar un servidor LAMP con usuarios adjuntos es totalmente diferente a ejecutar una PC de escritorio para la navegación web y la lectura de correo electrónico.
• Nivel de comodidad: nivel de usuario no obstante, si es técnicamente competente, pero no quiere pasar un fin de semana compilando un sistema, elegirá un padre principal, independientemente de si todos los que conoces eligen otra cosa.

Comentarios

• Esto es más específico utilizado en la geneaología de las distribuciones, en lugar de una comparación de las herramientas de administración de paquetes pacman y Debian ‘ …
• @jasonwryan Eso ‘ es el punto, ya que todos los administradores de paquetes realizan la misma tarea, es decir, emerge packagename es lo mismo que sudo apt-get install packagename.
• En ese nivel, sí; pero eso pierde por completo el sentido de la pregunta, es decir, qué diferencia a pacman de {apt, aptitude}.
• @jasonwryan Respondí eso en la sección The Bridge. Aparte de eso, no hay diferencia. Las únicas diferencias son semánticas, es decir, un comando frente a otro.Si el OP está buscando diferencias semánticas, hay un manual para eso.

Esto es por no significa una respuesta completa o exhaustiva: los carteles que tenía ante mí ya dieron algunos puntos muy buenos, solo me gustaría agregar mis 2 centavos. Otra cosa: nunca me acostumbré realmente a apt / dpkg. Siempre me pareció demasiado complejo yo, realmente me siento más cómodo con yum / rpm.

Pacman es muy fácil de usar, lo cual es una ventaja y una desventaja: puedes aprender a usarlo (aparte de la construcción de paquetes) en una sola tarde – utiliza principalmente funciones de administración de paquetes intuitivas y completas, pero – y este es un gran pero – es extremadamente inflexible.

Si los diseñadores no pensaron en una característica de antemano, estás jodido.

Algunos ejemplos: no hay versiones nativas en pacman. Si desea degradar la versión de un paquete, debe descargar esa versión del paquete en particular y usar la opción -U (actualización) para instalar desde el archivo. está muy orientado a siempre Está utilizando paquetes de última generación en su sistema.

No hay una verdadera limpieza de caché interna / reconstrucción completa. Si (debido a un problema de red) la descarga de un paquete se corrompió, por ejemplo, durante -Syu, el mensaje de error, aunque preciso, no será de mucha utilidad; no identificará el paquete corrupto incluso con la verbosidad «completa» y la depuración activada , y ninguna cantidad de -Syyc realmente limpiará el caché y volverá a descargar los paquetes. La buena noticia es que -Sc le permitirá saber dónde están los paquetes descargados para que pueda simplemente eliminar el ofensivo (si puede averiguar cuál es) o todos y reiniciar -Syu.

La integración de pacman con dkms también es algo problemática – mientras instalaba un nuevo kernel seguía teniendo errores de dkms. El uso de dkms build & & dkms install contra el nuevo kernel funcionó sin problemas, sin embargo, Pacman no ofrecería información alguna sobre por qué dkms falló durante la actualización del kernel (sospecho que nunca pasó la ruta correcta del nuevo kernel, y simplemente dejó que dkms usara el kernel predeterminado (en ejecución) pero con una versión incorrecta).

Otra anécdota sobre su inflexibilidad, como dijo, estoy acostumbrado a rpm / yum. Si tengo un archivo en mi sistema y deseo saber qué paquete es el propietario, puedo ejecutar yum proporciona / ruta / a / archivo y obtener TODOS los paquetes que pueden ponerlo allí, incluso si ninguno de ellos está instalado. Si el archivo se colocó manualmente y ahora deseo instalar un paquete, cambiará el nombre del nuevo (agregue la extensión .rpmnew) y me permitirá elegir qué usar.

Pacman simplemente elimina el error de un archivo ya existe, pero con un mensaje de error completamente irrelevante: se queja de conflictos entre el propietario «verdadero» del archivo y el paquete «filesystems» actualmente instalado, como si también fuera propietario del mismo archivo. Además, está orientado principalmente a la información instalada localmente; tratar de obtener información (como listas de archivos y propiedad) de paquetes que aún no se han instalado es menos intuitivo.

En pocas palabras, no es tan maduro como yum, y probablemente dpkg, que también le brinda facilidad de uso, es una relativa inflexibilidad.

Comentarios

• A falta de una completa falta de respuesta, Hay una serie de puntos que plantea que realmente son producto de una falta de familiaridad con pacman. Por ejemplo, pacman -Qo $file le dirá a qué paquete pertenece $ file. Además, toda su respuesta es una tontería, ya que el OP pidió explícitamente las diferencias entre Arch y Debian – yum no tiene nada que ver con eso …
• razón por la cual revelé explícitamente ese hecho al comienzo de mi respuesta. en cuanto al archivo -Qo $, ¿lo ha probado alguna vez con un paquete que aún no está instalado?
• No tiene sentido intentarlo con un paquete no instalado; hay otras herramientas para eso. Y la divulgación no ‘ t mitiga el hecho de que no ‘ t respondió la pregunta: un » comparación » entre yum y pacman no es igual a las diferencias entre Debian ‘ sy Arch ‘ s administradores de paquetes.
• @jasonwryan Por supuesto que hay un punto. Solo porque no ‘ no ve la necesidad de averiguar qué paquete podría tener un archivo, incluso si ‘ aún no está instalado, no ‘ t significa que tal necesidad no ‘ t existe. Ese era el punto. En cuanto a otras herramientas, ¿se basan en la necesidad de conocerlas? pacman es el administrador de paquetes. Con respecto a su punto principal, es posible que haya malinterpretado por completo la pregunta, pero asumí que se trataba de un PM ligero frente a un PM más complejo. Supongo que apt / dpkg es al menos tan complejo como yum / rpm, en cuanto a funciones.
• Mi punto es que está respondiendo una pregunta sobre la comparación de manzanas con naranjas al comparar su comprensión limitada de manzanas con peras. Y sí, has malinterpretado completamente la pregunta …