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

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

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.

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)

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.

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.