¿Cómo se rastrea qué paquetes se instalaron en Ubuntu (Linux)?


38

(Esta pregunta es muy similar a 10458. Se sugirió que Fedora y Ubuntu / Debian son lo suficientemente diferentes como para garantizar respuestas diferentes).

A medida que uso cualquier configuración de Ubuntu, instalo gradualmente una cantidad de paquetes que van más allá de la instalación de línea de base. Si reinstalo, o si necesito instalar una nueva máquina, generalmente quiero reinstalar esos paquetes específicos , y quiero hacerlo rápido para volver al trabajo con un mínimo de problemas. Por lo que yo he visto todos los gestores de paquetes ( apt-get, aptitudey synaptic) puede mi, lo cual se instalan los paquetes contar, y todos ellos tienen registros (aunque los diferentes para cada herramienta, que es una molestia). Pero ninguno de ellos puede decirme qué paquetes tengoinstalado, a diferencia de sus dependencias o actualizaciones del sistema. Incluso los registros son complicados porque no estoy completamente seguro de qué debo extraer de ellos o cómo integrarlos (en el caso de las diversas herramientas familiares aptas). Esto significa que cada vez que reinstalo, o incluso solo hago una copia de seguridad, no estoy seguro de cómo volver a crear esa lista.

No estoy esperando necesariamente que ninguna de las herramientas haga esto por mí, pero si no lo hacen, estoy buscando soluciones. Incluso los patrones a seguir, buenas reglas generales o una idea clara de lo que se está registrando exactamente, sería útil. Puede que no haya una "mejor respuesta" aquí, pero las buenas serían muy útiles.


La mayoría de las respuestas a continuación proporcionan una aproximación de lo que estoy buscando y son útiles hasta cierto punto. El elegido es el que más se acerca a una forma razonablemente automática de reinstalar mis herramientas en un nuevo sistema, incluso con todas sus advertencias.


No es probable que obtenga una respuesta fácil de compartir para todas las distribuciones de Linux. La administración de paquetes es una gran parte de lo que distingue las diferentes distribuciones de Linux.
Telemachus

Telémaco: cierto. Y puede tener sentido dividir esto en dos preguntas. Pero parecía una pregunta bastante especializada, y utilizo ambos sistemas, por lo que no quería reducirla demasiado de antemano. Parece que la mayoría de las respuestas aquí son para dpkg / apt, por lo que una pregunta separada para rpm / yum puede tener sentido.
quark

Cambie a NixOS :) (solo trolling).
Alexey

Respuestas:


31

En cualquier máquina basada en Debian, esta es una forma común de duplicar un conjunto de paquetes. En la vieja máquina:

dpkg --get-selections "*" > my_favorite_packages

Copie el archivo my_favorite_packagesa la nueva máquina (una memoria USB es una buena opción, pero scptambién funciona bien). Luego ejecute esta secuencia (con privilegios de root):

apt-get update
dpkg --set-selections < my_favorite_packages
apt-get -u dselect-upgrade

Esto no solo le proporciona los paquetes que instaló. También obtiene sus dependencias, etc. Además, si los repositorios entre las dos máquinas son diferentes, todas las apuestas están desactivadas.

En cuanto a los registros, apt-getmantiene un registro en /var/log/apt/history.log(gracias a Tshepang por actualizar esto en un comentario); dpkgdoes (at /var/log/dpkg.log), pero es difícil de analizar y solo se puede leer con privilegios de root; aptitudetiene uno en /var/log/aptitudey puede navegar a través de él con privilegios de usuario regulares.

Por lo que puedo decir, tiene razón en que ninguno de estos registros rastrea específicamente lo que instaló en lugar de las dependencias instaladas automáticamente. Sin embargo, puede obtener esa información de una aptitudebúsqueda. Busque todos los paquetes instalados que también se instalaron automáticamente:

aptitude search '~i ~M'

Si solo desea los que instaló (no las autodependencias), niegue ~M:

aptitude search '~i !~M'

Si desea que esté formateado para que solo tenga los nombres de los paquetes y la palabra "instalar", también aptitudepuede hacerlo. Esto le brinda una lista lista para alimentar a dpkg --get-selections:

aptitude search '~i !~M' -F "%p install"

(No tengo nada en RedHat o en los sistemas basados ​​en RedHat. Lo siento. Realmente no hay una respuesta para Linux per se ya que la administración de paquetes es una gran parte de lo que hace que las diferentes distribuciones sean diferentes ).


Parece una combinación de tus consejos y los de Ludwig podrían hacer el truco: aptitude puede generar un script para alimentar a dpkg, así que eso es automático, lo que es una victoria seria. Y si uno lo hiciera en la máquina de vainilla, la diferencia en las listas es lo suficientemente cercana a lo que estoy pidiendo para que sea prácticamente útil.
quark

3
Tenga en cuenta que ahora APT mantiene un registro de "/var/log/apt/history.log", y es utilizado por apt-get, synapticy aptitude(por lo que he visto). Esto es desde principios de 2010.
tshepang

Las dpkg.logdeclaraciones no parecen ser ciertas en Ubuntu 14.04 ya que cualquier usuario puede obtener mis selecciones fácilmente, no es trivial, pero no demasiado difícil. awk '$3 != "install" { next } ; { gsub(/:.+/, "", $4) ; print $4 }' /var/log/dpkg.log | sort | uniq
Steve Buzonas

En realidad, me doy cuenta de que no es tan fácil como pensaba inicialmente, la falla en el script awk anterior no presta atención a los paquetes desinstalados. Lo siguiente awk '$3 !~ /install|remove|purge/ { next } { gsub(/remove|purge/, "uninstall", $3) ; gsub(/:.+/, "", $4) ; a[$4]=$3 } END { for (p in a) { if (a[p] == "install") { print p } } }' /var/log/dpkg.log | sort -uhace.
Steve Buzonas

7

Úselo dpkg -l '*' > jaunty.originalpara recordar todos los paquetes instalados en un sistema recién instalado.

Después de haber instalado todos sus paquetes adicionales lo hacen dpkg -l '*' > mysystem.2009017.

Los paquetes adicionales son solo la diferencia: diff jaunty.original mysystem.2009017


3
La idea básica es sólida: use la línea de comandos para volcar la lista de aplicaciones instaladas actualmente, y luego use la línea de comandos para instalar esos paquetes en una nueva máquina. Puede ser bastante creativo y específico con el enfoque.
pcapademic

1
Prefiero dpkg --get-selections
CesarB

Si bien esto no rastrea los paquetes que agregué distintos de sus dependencias, definitivamente genera una lista útil.
quark

3

La aptitud es bastante buena en esto. Aptitude sabe cuándo se instaló algo a mano o por dependencia y puede decirle que elimine cosas que ya no son necesarias y que solo se instalaron porque algo más dependía de que siempre mantuviera su sistema lo más pequeño posible.

Hay un puñado de paquetes que conforman una instalación de Ubuntu, ubuntu-minimal, ubuntu-desktop, ubuntu-server, etc. Si le dice a Aptitude que los marque como instalados manualmente y elimine todo lo demás, entonces terminará con la cantidad mínima posible de paquetes.

Explico cómo hacer todo eso en dos publicaciones en mi blog: Limpiar un Debian GNU / Linux y Limpiar un Debian GNU / Linux (o Ubuntu), repita . En resumen, la respuesta que busca es:

aptitude search ~i | grep -v "i A"

La última vez que trabajé con eso, si usaste apt-get, entonces no funcionó. Es por eso que siempre recomiendo aptitude y, que yo sepa, Debian está despreciando apt-get a favor de aptitude.

No sé cómo hacerlo en Fedora y probablemente deberías separarte en una pregunta diferente. Fedora y Ubuntu son sistemas operativos diferentes y deben tratarse como tales (incluso si comparten su núcleo y algunas otras cosas).


2
Creo que puede obtener esa información sin necesidad grep: aptitude search '~i !~M'debería hacer el truco.
Telemachus

1
Además, apt-getno está en desuso. Debian recomienda la aptitudegestión de paquetes en la línea de comandos, pero eso está muy lejos de ser obsoleto apt-get.
Telemachus

Hay algo sutil aquí. Buscar "A" en la tercera columna parece marcar los paquetes que sé que están instalados como dependencias. Pero claramente no los atrapa a todos: la mayor parte de la lista definitivamente no fue instalada por mi solicitud explícita.
quark

@Telemachus. Su comando y el que tiene el patrón no hacen exactamente lo mismo: las dos listas tienen contenidos diferentes. Sin embargo, no sé lo suficiente sobre la aptitud para decirte por qué.
quark

@Pablo: los enlaces a su registro parecen estar rotos. Si puede solucionarlos, definitivamente querría leerlos.
quark

2

En debian apt-show-version muestra las versiones de los paquetes instalados.


Célebre. Esto no parece estar instalado (por defecto) en Ubuntu.
quark

1

En sistemas basados ​​en apt, mire /var/log/apt/term.log. Para mí, hay una línea bastante clara para dibujar dónde terminó la instalación y dónde comenzaron mis instalaciones.


Menos útil para mí, porque hay una mezcla de instalaciones manuales y actualizaciones del sistema. También, dependiendo de su término de configuración, los registros eventualmente estarán desactualizados y eliminados, por lo que no retrocederán tanto como lo necesito.
quark

Para cualquiera que intente esto, tenga en cuenta que leer el registro de apt parece ser mucho más trabajo que otras opciones discutidas aquí. Ciertamente, no es automático extraer una lista de paquetes del registro.
quark

1

De man aptitude-create-state-bundle:

aptitude-create-state-bundle produce un archivo comprimido que almacena los archivos necesarios para replicar el estado actual del archivo del paquete.

Esto retendrá la misma información que aptitudetiene sobre qué paquetes se instalaron manualmente.

Está destinado a ser utilizado con aptitude-run-state-bundle:

aptitude-run-state-bundle desempaqueta el paquete de estado de aptitud dado creado por aptitude-create-state-bundle (1) en un directorio temporal, lo invoca con el suministrado y luego elimina el directorio temporal.


1

Al usarlo dpkg, no sabe si el paquete fue instalado manualmente por el usuario o automáticamente (como una dependencia o durante la instalación inicial del sistema operativo). Si desea conservar esa información, debe obtener una lista de solo los paquetes que realmente se instalaron manualmente.

Para eso, puede usar cualquiera de estos dos one-liners. Ambos producen exactamente la misma salida en mi máquina y son más precisos que todas las soluciones propuestas hasta ahora en esta pregunta. Son una combinación de las dos respuestas (1) y (2) . Tenga en cuenta que originalmente publiqué esta respuesta aquí .

Utilizando apt-mark:

comm -23 <(apt-mark showmanual | sort -u) <(gzip -dc /var/log/installer/initial-status.gz | sed -n 's/^Package: //p' | sort -u)

Utilizando aptitude:

comm -23 <(aptitude search '~i !~M' -F '%p' | sed "s/ *$//" | sort -u) <(gzip -dc /var/log/installer/initial-status.gz | sed -n 's/^Package: //p' | sort -u)

Muy pocos paquetes aún se quedan atrás, aunque sospecho que estos son realmente instalados por el usuario, ya sea justo después de la instalación a través de la configuración de localización del idioma o, por ejemplo, a través del instalador de códec Totem. Además, las versiones de encabezado de Linux también parecen acumularse, aunque solo he instalado el metapaquete no específico de la versión. Ejemplos:

libreoffice-help-en-gb
openoffice.org-hyphenation
gstreamer0.10-fluendo-mp3
linux-headers-3.13.0-29    

Como funciona

  1. Obtenga la lista de paquetes instalados manualmente. Por aptitud, el adicional sedelimina el espacio en blanco restante al final de la línea.
  2. Obtenga la lista de paquetes instalados inmediatamente después de una nueva instalación.
  3. Compare los archivos, solo muestre las líneas del archivo 1 que no están presentes en el archivo 2.

Otras posibilidades no funcionan tan bien:

  • Usando el ubuntu-14.04-desktop-amd64.manifestarchivo ( aquí para Ubuntu 14.04) en lugar de /var/log/installer/initial-status.gz. Se muestran más paquetes como instalados manualmente aunque no lo sean.
  • Usando en apt-mark showautolugar de /var/log/installer/initial-status.gz. apt-markpor ejemplo, no incluye el paquete xserver-xorg, mientras que el otro archivo sí.

Ambos enumeran más paquetes que la solución anterior.


0

Soy parcial y la solución que presento no siempre es posible, pero me cansé de esta situación. El resultado es que ya no instalo nada con las herramientas de actualización / administrador de paquetes.

Sin embargo, tomé una ruta bastante difícil (tenía requisitos estrictos para las versiones). Creé un enorme archivo MAKE que descarga, compila e instala en mi directorio de inicio cada paquete (programa, biblioteca, lo que sea) que necesito. Lo desarrollé paso a paso, pieza por pieza. El archivo MAKE descarga y compila todo, incluso los compiladores.

Cuando me mudo a un nuevo sistema, o lo reinstalo, solo copio el archivo MAKE (más algunas cosas de soporte), ejecuto make world y vuelvo al día siguiente.

Para algunos programas que desarrollo (por lo que tengo control), uso una herramienta que programé, el administrador de paquetes de la castaña . Algo así como carpetas .app en MacOSX. Todo está en el paquete, así que sé lo que está instalado en cualquier momento, y sé que es autónomo y autosuficiente (excepto las bibliotecas del sistema)


Simplemente puede poner los comandos de instalación del administrador de paquetes en un script y tener el mismo efecto; asumiendo que el código que necesita está empaquetado. Su enfoque se parece mucho al de gentoo.
wcoenen

Es bueno saberlo. Parece mucho trabajo adicional más allá de un sistema Ubuntu / Debian predeterminado. Puedo ver el mantenimiento manual de algunos paquetes, pero mantenerlos todos de esta manera es más trabajo del que quiero hacer.
quark

Sí, pero con el problema adicional de que las cosas de ubuntu / fink / darwinports no funcionan multiplataforma en todas partes (una vez estuve en una digital e IBM sp4). No digo que esta sea una buena manera de hacerlo. Solo digo que hace el trabajo, aunque de una manera fea y maloliente, y mantengo el control total de lo que sucede en mi sistema.
Stefano Borini

Por supuesto, podría decidir uno de estos días para realmente tomar una mirada seria para emerger y reelaborar todo con él.
Stefano Borini

Este camino es más común en estos días cuando considera herramientas como chef y títeres.
Steve Buzonas
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.