dpkg
usa un archivo de bloqueo ( /var/lib/dpkg/lock
), cuando está en uso.
- ¿Por qué se necesitan estos archivos de bloqueo?
- ¿Por qué no son posibles varias instancias?
dpkg
usa un archivo de bloqueo ( /var/lib/dpkg/lock
), cuando está en uso.
Respuestas:
Este no es un dpkg
problema específico (como sugiere el título de mi edición). Más bien, esto es algo que hace todo administrador de paquetes (del cual tengo conocimiento); Y por una buena razón. Sin embargo, entiendo por qué puede ser confuso.
Los administradores de paquetes confían en las bases de datos para rastrear la información de los paquetes instalados. Si varios usuarios intentan escribir en una base de datos al mismo tiempo, tiene una alta probabilidad de corromper los datos (lo que realmente afectaría al sistema).
Como resultado, muchos administradores de paquetes (¿todos?) Confían en un archivo de bloqueo para indicar que se está escribiendo en la base de datos, por lo que no se debe permitir que otro cliente lo haga.
Tenga en cuenta que los administradores de paquetes inteligentes pueden determinar cuándo una solicitud es de solo lectura y es posible que no necesite bloquear la base de datos. Como resultado; Es posible que algunas acciones puedan ejecutarse simultáneamente donde otras no lo estarán.
El archivo de bloqueo se usa para evitar la ejecución paralela de varias instancias.
¿Por qué es esto importante para un administrador de paquetes?
Un administrador de paquetes, desde una vista de alto nivel, es un programa que aplica cambios complejos al disco duro.
Los cambios no se pueden hacer en un solo paso ("atómico"), por lo que hay varios pasos; Muchos de los pasos dependen del resultado de los pasos anteriores.
Por lo tanto, el administrador de paquetes debe analizar el disco duro antes de ejecutar cada paso, o simplemente analizarlo una vez y realizar un seguimiento de los cambios que aplica. La primera opción es extremadamente lenta. El segundo requiere que ninguna otra instancia realice cambios.
Hay muchos otros problemas que podrían aparecer.
No es imposible implementar un administrador de paquetes que pueda funcionar en paralelo, pero es demasiado complicado como para que valga la pena . Como en, no te puedes imaginar lo complicado. De Verdad.
dkpg
(y la rpm
mayoría de los otros administradores de paquetes tradicionales) funcionan instalando paquetes en un espacio global, lo que significa que los paquetes pueden entrar en conflicto entre sí (por ejemplo, A
y B
no pueden instalarse al mismo tiempo, porque ambos se instalan /usr/lib/libfoo.so
). Los administradores de paquetes deben detectar tales conflictos y rechazar dichas solicitudes de instalación para mantener el sistema en un estado coherente. Tener varias instancias del administrador de paquetes ejecutándose al mismo tiempo sería muy complicado y propenso a errores.
Los administradores de paquetes libres de conflictos (por ejemplo, http://0install.net ) pueden y permiten que se instalen múltiples paquetes en paralelo¹, y no necesitan archivos de bloqueo ( A/libfoo.so
e B/libfoo.so
irán en diferentes directorios).
1 Paralelo en el sentido de estar presente y disponible en el sistema al mismo tiempo, y en el sentido de ser descargado y agregado al sistema al mismo tiempo.