¿Cómo mantienen los administradores de paquetes de Linux el gráfico acíclico dirigido que forman los paquetes?

La versión corta:

  • Una base de datos de “Paquete requiere Paquete”
  • cosas que leen e interpretan la base de datos como un DAG
  • cosas que imitan los cambios en la base de datos antes de que sucedan usando reglas
  • un índice de cosas deseadas
  • un sistema de recolección de basura que puede cosechar cosas que ya no quería cosas o dependencias de cosas no deseadas mediante técnicas recursivas.

En Gentoo, el Gráfico Acíclico Dirigido (DAG) realmente no existe fuera del proceso de emergencia. Lo hace, pero en forma abstracta.

Esencialmente, tiene una “raíz de árbol”, que contiene un superconjunto de todos los paquetes que son “deseados”.

Todos los demás paquetes en el sistema son meramente “dependencias de paquetes que se desean”.

En gentoo, la raíz del árbol se compone de dos partes centrales:

1. Un conjunto de sistemas, que está dictado por el perfil que esté utilizando.
2. Un archivo mundial, que contiene la lista de requisitos especificados por el usuario.

[mundo + sistema] -> x -> z
-> y -> z

Los elementos de ese DAG se almacenan en una colección de archivos que se aproximan a una lista de asociaciones.

x -> a, b, c,! f
y -> a, d, e,! g

Dado eso, es razonablemente sencillo cargar solo subconjuntos parciales del gráfico de dependencia total según sea necesario.

Instalar un nuevo paquete o una nueva versión solo necesita asegurarse de que no haya paquetes que bloqueen su instalación, y esa parte es casi lineal.

(Es decir, iterar el lado derecho del conjunto anterior y simplemente asegurarse de que la nueva versión no entre en conflicto con los requisitos existentes)

Más allá de eso, es principalmente la recursión, y la recursión que simplemente requiere que haya una posible ruta acíclica en el momento de la instalación.

En teoría, incluso puede establecer ciclos en el DAG, por lo que no es realmente un DAG, siempre que pueda establecer el ciclo en etapas.

(Estoy eludiendo una gran cantidad de componentes internos, principalmente porque es realmente complejo y realmente no entiendo esa parte)

Sí, la mayor parte de esto significa que Gentoo tiene que volver a cargar y reconstruir todo el gráfico (o un subgrafo) cada vez que ejecuta la herramienta emergente, pero eso no es realmente tan malo.

Pero el diseño también hace que sea razonablemente simple determinar cosas que ya no son necesarias simplemente por no tener antepasados ​​en el conjunto raíz.

En cuanto a la desinstalación, no es estándar que opte por desinstalar una cosa, y que todas las cosas que lo requieran se desinstalarán automáticamente, lo que tiende a romperlas accidentalmente.

Por lo general, se alienta a las personas a decir: “emerge –depclean foo”, que hace un análisis simulado de eliminación y ve qué cosas se romperían con la eliminación. Y, por lo general, las personas prefieren * no * eliminar cosas que podrían romper otras al eliminarlas.

En cambio, las personas simplemente eliminan cosas de la raíz del nivel superior, y si ya no son necesarias para nada, son cosechadas y todas sus dependencias que ya no son necesarias se cosechan con ellas.

[mundo] -> x -> a, b, c
-> y -> a, c

eliminar x, x y b se desinstala.

[mundo] -> y -> a, c

Y si todavía son necesarios, todo lo que sucede es que el sistema reconoce “El usuario ya no solicitó que se guarde” y luego puede ser candidato para su eliminación si algo más que anteriormente requería ya no lo hace.

[mundo] -> x -> a, b, c
-> y -> x, a, c

intentar eliminar x dice “romperás y”, por lo que si eliminas x de “mundo”, nada cambia.

[mundo] -> y -> x, a, c -> b

eliminar y; x, a, c y b se eliminan como resultado debido a que ya no se requieren.

Recibí una respuesta parcial por esta vez. Hay un archivo de registro de instalaciones, pero no creo que se molesten en analizar eso.

Es posible que haya un archivo binario que cuente cuántos paquetes usan una biblioteca, y cuando instala algo nuevo, aumenta el número de esa dependencia.