Seguimiento de programas

Cuando instalo un programa simple, a menudo usa make && make instally ni siquiera tiene un objetivo de desinstalación .

Si deseo actualizar un programa, ¿es un protocolo estándar asumir que simplemente se reescribe sin problemas sobre el programa anterior?

¿Cómo hago un seguimiento de estos programas? ¿La mayoría de las personas simplemente 'disparan y olvidan' y si no se proporciona un objetivo de desinstalación , tengo que eliminar todo manualmente?

Instale cada programa en un árbol de directorios dedicado y use Stow o XStow para que todos los programas aparezcan en una jerarquía común. Stow crea enlaces simbólicos del directorio específico del programa a un árbol común.

Con más detalle, elija un directorio de nivel superior, por ejemplo /usr/local/stow. Instale cada programa debajo /usr/local/stow/PROGRAM_NAME. Por ejemplo, organice la instalación de sus ejecutables /usr/local/stow/PROGRAM_NAME/bin, sus páginas de manual, /usr/local/stow/man/man1etc. Si el programa usa autoconf, ejecute ./configure --prefix /usr/local/stow/PROGRAM_NAME. Después de que hayas corrido make install, corre stow:

./configure --prefix /usr/local/stow/PROGRAM_NAME
make
sudo make install
cd /usr/local/stow
sudo stow PROGRAM_NAME

Y ahora tendrás enlaces simbólicos como estos:

/usr/local/bin/foo -> ../stow/PROGRAM_NAME/bin/foo
/usr/local/man/man1/foo.1 -> ../../stow/PROGRAM_NAME/man/man1/foo.1
/usr/local/lib/foo -> ../stow/PROGRAM_NAME/lib/foo

Puede hacer un seguimiento fácil de los programas que ha instalado enumerando el contenido del stowdirectorio, y siempre sabe a qué programa pertenece un archivo porque es un enlace simbólico a una ubicación en el directorio de ese programa. Desinstale un programa ejecutando y stow -D PROGRAM_NAMEluego eliminando el directorio del programa. Puede hacer que un programa no esté disponible temporalmente ejecutando stow -D PROGRAM_NAME(ejecute stow PROGRAM_NAMEpara que esté disponible nuevamente).

Si desea poder cambiar rápidamente entre diferentes versiones del mismo programa, úselo /usr/local/stow/PROGRAM_NAME-VERSIONcomo el directorio del programa. Para actualizar de la versión 3 a la versión 4, instale la versión 4, luego ejecute stow -D PROGRAM_NAME-3; stow PROGRAM_NAME-4.

Las versiones anteriores de Stow no van mucho más allá de lo básico que describí en esta respuesta. Las versiones más recientes, así como XStow (que no se ha mantenido últimamente) tienen características más avanzadas, como la capacidad de ignorar ciertos archivos, hacer frente mejor a los enlaces simbólicos existentes fuera del directorio de almacenamiento (como man -> share/man), manejar algunos conflictos automáticamente (cuando dos los programas proporcionan el mismo archivo), etc.

Si no tiene o no desea utilizar el acceso raíz, puede elegir un directorio en su directorio de inicio, por ejemplo ~/software/stow. En este caso, agregue ~/software/bina su PATH. Si manno encuentra automáticamente páginas de manual, agréguelas ~/software/mana su MANPATH. Agregue ~/software/infoa su INFOPATH, ~/software/lib/pythona su PYTHONPATH, etc., según corresponda.

Puede usar checkinstall para crear un paquete (paquetes compatibles con RPM, Deb o Slackware) De esa manera, puede usar su administrador de paquetes de distribución para agregar / eliminar la aplicación (pero no actualizar)

Usted usa checkinstallen lugar del make installcomando (usando el parámetro -D para Deb; -R es RPM y -S es Slackware):

root@nowhere# ./configure
root@nowhere# make
root@nowhere# checkinstall -D

checkinstall compilará e instalará el paquete de manera predeterminada, o puede hacer que solo compile el paquete sin instalarlo.

checkinstall está disponible en la mayoría de los repositorios de distros.

En su mayor parte, esta fue la razón detrás de los paquetes, puertos y otros tipos de administradores para evitar que este tipo de cosas sucedan.

Yo diría que la eliminación manual es la única forma de una instalación manual, a menos que alguien más tenga una mejor respuesta a ese punto que no conozco.

Una alternativa más es de las sugerencias de Linux From Scratch :

Más control y gestión de paquetes con usuarios de paquetes

3 Usuarios del paquete
3.1 Introducción

La idea básica de este esquema se explica fácilmente. Cada paquete pertenece a un determinado "usuario del paquete". Cuando instala un paquete, construye e instala el paquete como este usuario del paquete, lo que hace que todos los archivos instalados sean propiedad del usuario del paquete. Como consecuencia, todas las tareas habituales de administración de paquetes se pueden lograr cómodamente mediante el uso de utilidades de línea de comandos estándar. Un simple ls -l <file>le indicará, por ejemplo, a qué paquete <file>pertenece y un find -user ...comando le permite realizar una operación en todos los archivos que pertenecen a un determinado paquete, por ejemplo, eliminarlos para desinstalar el paquete.

Pero la administración de paquetes no es todo para lo que los usuarios de paquetes son buenos. Debido a que los usuarios de paquetes no tienen derechos de root, la instalación de un paquete está limitada en lo que puede hacer. Una cosa que un usuario de paquete no puede hacer, por ejemplo, es sobrescribir archivos de un usuario de paquete diferente. Los enfrentamientos entre diferentes paquetes que desean instalar un archivo binario, de biblioteca o de encabezado con el mismo nombre son más comunes de lo que parece. Con los usuarios de paquetes, nunca corre el riesgo de que la instalación del paquete B destruya archivos del paquete A silenciosamente sin que lo note. Cada intento de hacer esto durante la instalación del paquete B provocará un error de "Permiso denegado" o "Operación no permitida" para que tenga la posibilidad de tomar las medidas adecuadas. Otra cosa que los usuarios de paquetes no pueden hacer es instalar binarios raíz setuid. La decisión de hacer una raíz setuid binaria también es algo que un administrador prudente no quiere dejar al creador de un paquete de software.

Por lo general, las cuentas de usuario del paquete no tienen una contraseña válida, por lo que solo el su usuario root puede acceder a un usuario del paquete, lo que garantiza que los usuarios del paquete no abran una vía adicional en el sistema y socaven la seguridad. Pero puede establecer contraseñas de todos modos para permitir que un coadministrador que desee pueda instalar y mantener ciertos paquetes de software para hacerlo sin tener acceso a la cuenta raíz real. Este coadministrador podría, por ejemplo, instalar, eliminar, cambiar bibliotecas adicionales que podrían ser necesarias para su grupo de trabajo. Sin embargo, no podría eliminar o modificar bibliotecas que no le pertenecen, como libc.

Después de esta primera sugerencia cruda, encontré una variante evolucionada:

crablfs - Sistema de gestión de paquetes basado en el usuario

Este crablfses el último espécimen de administración de paquetes que usa uids y gids únicos para la administración de paquetes, pero en sourceforge está evolucionando nuevamente en ulfs:

uLFS: su Linux manejable y reutilizable desde cero

Para los usuarios causales de paquetes instalados, creo que la solución LFS para "usuarios de paquetes" es ligera, menos invasiva y elegante. En resumen, instala paquetes en /usr/localo /home/user/localy rastrea archivos usando uids y gids únicos para cada paquete pero coloca todos los archivos en los lugares tradicionales, directorios comunes /usr/local/bin, /usr/local/libcomo en todas las distribuciones de Linux convencionales ... oclusión de archivos y sobrescritura o eliminación de archivos no deseados es evitado por un truco ordenado de Linux explicado por Matthias S. Benkmann en more_control_and_pkg_man.txt que solo necesita manipulación de permisos de archivos y directorios normales, por ejemplo, el permiso de bits fijos para directorios para evitar sobrescrituras de archivos no deseados:

3.3 Grupos

Cada usuario del paquete pertenece al menos a 2 grupos. Uno de estos grupos es el grupo "instalar", al que pertenecen todos los usuarios del paquete (y solo los usuarios del paquete). Todos los directorios en los que los paquetes pueden instalar cosas pertenecen al grupo de instalación. Esto incluye directorios como / bin y / usr / bin pero excluye directorios como / root o /. Los directorios que posee el grupo de instalación siempre se pueden escribir en grupo. Esto sería suficiente para los aspectos de administración de paquetes, pero sin una preparación adicional no daría mayor seguridad o control porque cada paquete podría reemplazar los archivos de un paquete diferente (el cambio sería visible en el resultadols -l, aunque). Por esta razón, todos los directorios de instalación obtienen el atributo adhesivo. Esto permite a los usuarios crear nuevos archivos y eliminar o modificar sus propios archivos en el directorio, pero los archivos de otros usuarios no pueden modificarse ni eliminarse. En el resto de esta sugerencia, cada vez que se utiliza el término "directorio de instalación", se refiere a un directorio que pertenece a la instalación grupal, se puede escribir en grupo y se pega. IOW, para convertirlo <dir>en un directorio de instalación que haría

instalación de chgrp && chmod g + w, o + t

¡Para mí parece una solución simple e inteligente! Usé este esquema en mi compilación LFS y es una solución que funciona ...

1. Puede hacer un RPM vacío como recordatorio.
2. Puede buscar envolver el software correctamente en un RPM.
3. Puede dejar una copia de los tararchivos de la instalación /usr/src/non-rpmspara recordarle (eso es lo que suelo hacer).