Diferencias en la gestión de paquetes entre Debian y Arch

9

Una discusión de esta publicación me hizo sentir curiosidad por las diferencias entre la gestión de paquetes Debian y Arch. Además, la gente tiende a decir que Arch es muy liviano, por lo que me pregunto qué tiene que ver eso con la administración de paquetes. ¿Es quizás porque Debian trata Recommends como dependencias duras por defecto?

¿Puede mencionar también la flexibilidad / potencia entre los dos administradores de paquetes: cuál de los dos le permite hacer más?

Soy consciente de que algunas funciones disponibles en un sistema de gestión de paquetes de Debian serían irrelevantes en un sistema Arch, ya que Arch tiene una única suite y Debian tiene múltiples (por ejemplo, fijación de APT y manejo avanzado de dependencias), así que compare las funciones que son aplicables a ambos sistemas (es decir, supongamos que para Debian, solo uso inestable ).

tshepang
fuente
NOTA : Por la gestión de paquetes de Debian me refiero a APT, aptitude y dpkg. No estoy familiarizado con las herramientas de Arch, así que no sé si hay algo más que Pacman.
tshepang

Respuestas:

7

Solo uso el arco 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 notado sobre la "flexibilidad / potencia":

  • 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. Si bien 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, de unos días de antigüedad) intentó mejorar el rendimiento al reducir la cantidad de archivos de base de datos involucrados.

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

  • Crear paquetes es muy fácil y rápido, solo unas pocas líneas en un archivo PKGBUILD y listo, no es necesario lidiar con control / reglas / derechos de autor / registro de cambios / lo que sea con los paquetes de Debian. Y en 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 el arco:

  • Disparadores / ganchos (lo que hace que apt actualice el caché de iconos, el mandb o lo que sea simplemente mirando dónde están los archivos de instalación 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 cosas manualmente, me obliga a saber qué se hace exactamente) y el manejo adecuado de los nuevos archivos de configuración (al menos me gustaría que Pacman sepa cuándo un archivo de configuración en un nuevo paquete la versión es diferente de la instalada porque se cambió en la nueva versión o porque la modifiqué localmente).

  • firma del paquete (parece que se está trabajando ).

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

caballero
fuente
No puedo analizar esto: pero puedo prescindir de él y, por cierto, saber qué hago mejor . También hay un error tipográfico en la última oración.
tshepang
¿En qué idioma está escrito el administrador de paquetes pacman? ¿Tiene una funcionalidad de administración de paquetes de bajo y alto nivel similar a dpkg / apt, y si es así, cómo se llaman?
Faheem Mitha
@Tshepang: lo siento, no hablo inglés nativo aquí. Quise decir que "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".
gentledevil
@Faheem Mitha: Pacman está escrito en C y es una interfaz para libalpm, que maneja la gestión de paquetes de "alto nivel" y "bajo nivel".
gentledevil
@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 misma. Por cierto, el error tipográfico que mencioné es opcional . Podría editar la publicación yo mismo, pero pensé que también podría solucionarlo junto con la parte de aclaración.
tshepang
6

Comencé mi viaje por Linux con Ubuntu lúcido, 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 ganchos para paquetes, conocido como an install file.

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

Además, noté que mencionó 'anclar' una aplicación usando herramientas de administración de paquetes de Debian; Arch's pacman también tiene eso incorporado, /etc/pacman.confacepta una serie de configuraciones, que incluyen IgnorePkg =, lo que evitará actualizaciones a cualquier paquete enumerado después de los iguales (delimitado por espacios)

hanetzer
fuente
1
Además, si bien no es un paquete de repositorio, puede usar el powerpillcontenedor para que pacman tenga descargas paralelas de múltiples paquetes, por lo que en lugar de pacman -S libfoo libbar libbazdescargar cada paquete uno tras otro, descargará los tres simultáneamente, aumentando en gran medida las velocidades de actualización para mejores conexiones.
hanetzer
-1

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

Para comprender las diferencias en los gestores de paquetes, debe comprender las filosofías de los sistemas operativos que se muestran arriba


Tres padres principales

  1. Redhat, ahora Fedora - Administrador de paquetes - RPM, abreviatura de Redhat Package Manager, línea de comando rpm
  2. Slackware - Package Manager - tgz, archivos comprimidos ordinarios. Aunque estos son solo archivos comprimidos, fueron creados por Slackware aguas arriba y colocados en un repositorio, a veces denominado puerto
  3. Debian - DEB, abreviatura de Debian, su herramienta de línea de comando 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ó de alguna forma o forma. En cualquier caso, 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 fuente, sin administrador de paquetes.
  2. Gentoo: derivado de Linux de Scratch . Esta distribución es esencialmente Linux de Scratch más un administrador de paquetes, llamado Portage / emerge
  3. SourceMage - Hechicero de Package Manager

Estos padres son menores porque su base de usuarios intercambia 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.

El puente

Arch se creó como un puente entre una distribución binaria, como uno de los 3 padres principales, y una distribución basada en la fuente como uno de los 3 padres menores. Como tal, recibe el estado como 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 el Sistema Arch Build. Este concepto proporciona un equilibrio entre el poder que otorgan los padres menores con la facilidad de instalación que otorgan 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 como:

  • Nivel de usuario: alguien nuevo en Linux debería comenzar con un padre mayor, mientras que alguien técnicamente competente encontrará un equilibrio.
  • Lo que desea hacer con su sistema: ejecutar un servidor LAMP con usuarios conectados es totalmente diferente a ejecutar una PC de escritorio para navegar por Internet y leer correos electrónicos.
  • Nivel de comodidad: no obstante el nivel de usuario, si eres técnicamente competente, pero no quieres pasar un fin de semana compilando un sistema, elegirás un padre principal, independientemente de si todos los que conoces eligen algo más.
eyoung100
fuente
Esto se centra más en la geneaología de las distribuciones, en lugar de una comparación de las herramientas de gestión de paquetes de pacman y Debian ...
jasonwryan
@jasonwryan Ese es el punto, ya que todos los administradores de paquetes realizan la misma tarea, emerge packagenamees decir, es lo mismo sudo apt-get install packagename.
eyoung100
A ese nivel, sí; pero eso pierde por completo el punto de la pregunta, es decir, lo que diferencia a pacman de {apt, aptitude}.
jasonwryan
@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 versus otro. Si el OP está buscando diferencias semánticas, hay un manual para eso.
eyoung100
-3

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

Pacman es muy fácil de usar, lo cual es un profesional y un contra. Puede aprender a usarlo (dejando de lado la creación de paquetes) en una sola tarde. Utiliza funciones de administración de paquetes principalmente intuitivas y completas, pero, y esto 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 una versión del 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 utilizar siempre paquetes de vanguardia en su sistema.

No hay limpieza interna de caché real / reconstrucción completa. Si (debido a un problema de red) se corrompió la descarga de un paquete, por ejemplo, durante -Syu, el mensaje de error, si bien es preciso, no será de mucha utilidad: no identificará el paquete corrupto incluso con verbosidad "completa" y 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 ofensor (si puede descubrir 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 núcleo, 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 use el valor predeterminado (ejecución actual) kernel pero con versión incorrecta).

Otra anécdota sobre su inflexibilidad: como se dijo, estoy acostumbrado a rpm / yum. Si tengo un archivo en mi sistema y deseo saber qué paquete lo posee, puedo ejecutar yum provide / path / to / file y obtener TODOS los paquetes que pueden colocarlo 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 (agregará la extensión .rpmnew) y me permitirá elegir qué usar.

pacman simplemente elimina el error de que ya existe un archivo, pero con un mensaje de error completamente irrelevante: se queja de conflictos entre el propietario "verdadero" del archivo y el paquete de "sistemas de archivos" 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 están instalados es menos intuitivo.

En pocas palabras: no es tan maduro como yum, y probablemente dpkg, lo que se presta a su facilidad de uso también es una relativa inflexibilidad.

Dani_l
fuente
1
A falta de una no respuesta exhaustiva, hay una serie de puntos que plantea que realmente son producto de una falta de familiaridad con pacman. Por ejemplo, pacman -Qo $filele dirá qué paquete posee $ file. Además, todo tu respuesta es un hombre de paja como el OP pedido explícitamente las diferencias entre Arch y Debian - yumno tiene nada que ver con esto ...
jasonwryan
Por eso he revelado explícitamente ese hecho al comienzo de mi respuesta. en cuanto al archivo -Qo $, ¿alguna vez has probado eso para un paquete que aún no está instalado?
Dani_l
No tiene sentido probarlo para un paquete no instalado; Hay otras herramientas para eso. Y la divulgación no mitiga el hecho de que no haya respondido la pregunta: una "comparación" entre yum y pacman no es lo mismo que las diferencias entre los administradores de paquetes de Debian y Arch.
jasonwryan
@jasonwryan Por supuesto que hay un punto. El hecho de que no vea la necesidad de averiguar qué paquete podría poseer un archivo, incluso si aún no está instalado, no significa que tal necesidad no exista. Ese era el punto. En cuanto a otras herramientas, ¿son necesarias para conocerlas? Pacman es el administrador de paquetes. Con respecto a su punto principal: es posible que haya leído completamente la pregunta, pero supuse 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 función de las características.
Dani_l
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 leído mal la pregunta por completo ...
jasonwryan