6.3. Adiministración de paquetes

Frecuentemente se solicita la inclusión de la administración de paquetes en el libro LFS. Un administrador de paquetes permite supervisar la instalación de ficheros facilitando la eliminación y actualización de ficheros. Y antes de que empieces a preguntar, NO, esta sección no habla sobre un administrador de paquetes en concreto, ni recomienda alguno. Lo que suministra es un paseo por las técnicas más populares y su método de trabajo. El administrador de paquetes perfecto para ti puede encontrarse entre estas técnicas o puede ser una combinación de dos o más de ellas. Esta sección menciona brevemente los problemas que pueden surguir cuando se actualizan paquetes.

Algunas razones por las que ningún administrador de paquetes se menciona en LFS or BLFS:

Se han escrito diversas recetas sobre este tema. Visita el Proyecto Hintspara ver si alguna de ellas cubre tus necesidades.

6.3.1. Cuestiones de actualización

Un administrador de paquetes facilita la actualización a nuevas versiones cuando estas son liberadas. Generalmente se pueden usar las instrucciones de los libros LFS y BLFS para actualizar a la nueva versión. A continuación hay algunos puntos que debes tener en cuenta cuando actualices paquetes, especialmente en sistemas en ejecución.

  • Si necesitas actualizar uno de los paquetes de las herramientas principales (Glibc, GCC o Binutils) a una nueva versión menor, es más seguro reconstruir el LFS. Aunque podrías ser capaz de reconstruir todos los paquetes en su orden de dependencias, no lo recomendamos. Por ejemplo, si necesitas actualizar de glibc-2.2.x a glibc-2.3.x, es más seguro reconstruir. Para actualizaciones de micro-versión, una simple reinstalación funciona normalmente, pero no está garantizado. Por ejemplo, actualizar de glibc-2.3.4 a glibc-2.3.5 no suele causar problemas.

  • Si se actualiza un paquete que contiene una librería compartida, y si el nombre de la librería cambia, entonces necesitas recompilar todos los paquetes enlazados dinámicamente a esa librería para que se enlacen contra la nueva. (Advierte que no hay correlación entre la versión del paquete y el nombre de la librería.) Por ejemplo, considera un paquete foo-1.2.3 que instala una librería compartida con el nombre libfoo.so.1. Digamos que actualizas el paquete a la nueva versión foo-1.2.4 que instala una librería compartida de nombre libfoo.so.2. En este caso, todos los paquetes que están enlazados dinámicamente a libfoo.so.1 deben recompilarse para que se enlacen contra libfoo.so.2. Ten en cuenta que no deberías eliminar las librerías anteriores hasta recompilar los paquetes dependientes.

6.3.2. Técnicas de administración de paquetes

Lo siguiente son algunas técnicas comunes de administración de paquetes. Antes de tomar una decisión sobre un administrador de paquetes, haz una búsqueda de las diversas técnicas, particularmente de los inconvenientes de cada uno.

6.3.2.1. ¡Todos está en mi cabeza!

Si, esta es una técnica de administración de paquetes. Algunas personas no encuentran necesario un administrados de paquetes porque conocen íntimamente los paquetes y saben qué ficheros instala cada paquete. Algunos usuarios tampoco lo necesitan porque piensan reconstruir el sistema al completo cuando cambia un paquete.

6.3.2.2. Instalar en directorios separados

Esta es una administración de paquetes muy simple que no necesita paquetes adicionales para manejar la instalación. Cada paquete se instala en un directorio aparte. Por ejemplo, el paquete foo-1.1 se instala en /usr/pkg/foo-1.1 y se hace un enlace simbólico de /usr/pkg/foo a /usr/pkg/foo-1.1. Cuando se instala una nueva versión foo-1.2, esta se instala en /usr/pkg/foo-1.2 y el anterior enlace se reemplaza por un enlace a la nueva versión.

Las variables de entorno como PATH, LD_LIBRARY_PATH, MANPATH, INFOPATH y CPPFLAGS deben expandirse para incluir /usr/pkg/foo. Para más de unos pocos paquetes este esquema se hace inmanejable.

6.3.2.3. Administración de paquetes por medio de enlaces

Esta es una variante de la técnica anterior. Cada paquete se instala de forma similar a la del esquema anterior. Pero en vez de hacer el enlace, cada fichero se enlaza en la jerarquía /usr. Esto elimina la necesidad de ampliar las variables de entorno. Aunque el usuario puede crear los enlaces, para automatizar su creación se han escrito diversos administradores de paquetes basados en este sistema. Algunos de los más populares son Stow, Epkg, Graft, y Depot.

Es necesario falsear la instalación, para que el paquete piense que se instala en /usr aunque en realidad sea instalado en la jerarquía /usr/pkg. Instalar de esta forma no es una tarea trivial. Por ejemplo, considera que instalas un paquete libfoo-1.1. Las siguientes instrucciones no instalarán el paquete correctamente:

./configure --prefix=/usr/pkg/libfoo/1.1
make
make install

La instalación funcionará, pero los paquetes que dependan de ella no se enlazarán con libfoo como cabría esperar. Si compilas un paquete que se enlaza contra libfoo advertirás que se enlaza a /usr/pkg/libfoo/1.1/lib/libfoo.so.1 en lugar de /usr/lib/libfoo.so.1 como esperabas. El método correcto es usar la estratégia DESTDIR para falsear la instalación del paquete. Este método funciona así:

./configure --prefix=/usr
make
make DESTDIR=/usr/pkg/libfoo/1.1 install

La mayoría de los paquetes soportarán este método, pero algunos no. Con los paquetes que no lo soportan puedes instalarlos manualmente o te será más facil instalar algún paquete problemático en /opt.

6.3.2.4. Basado en marcas de fecha

En esta técnica, un fichero es marcado con la fecha antes de instalar el paquete. Tras la instalación, un simple comando find con las opciones apropiadas puede generar un registro de todos los ficheros instalados tras la creaciónh del fichero marcado. Un administrador de paquetes escrito con este método es install-log.

Aunque este esquema tiene la ventaja de ser simple, tiene dos inconvenientes. Si durante la instalación los ficheros se instalan con una marca de fecha diferente a la actual, estos ficheros no serán registrados por el administrador de paquetes. Igualmente, este esquema solo puede usarse instalando un paquete cada vez. Los registros no serán válidos si se están instalando dos paquetes desde dos consolas diferentes.

6.3.2.5. Basado en LD_PRELOAD

En este método se precarga una librería antes de la instalación. Durante la instalación esta librería supervisa los paquetes que están siendo instalados adjuntandose ella mismo a varios ejecutables como cp, install, mv y supervisa las llamadas del sistema que modifican el sistema de ficheros. Para que este método funcione todos los ejecutables deben estar enlazados dinámicamente y sin los bits suid o sgid. Precargar la librería puede causar algunos efectos indeseados durante la instalación, por lo que se han de realizar algunas pruebas para asegurar que el administrador de paquetes no rompe nada y registrar todos los ficheros pertinentes.

6.3.2.6. Crear archivos de paquetes

En este esquema la instalación del paquete es falseada dentro de un árbol separado, como se describe en la administración de paquetes por medio de enlaces. Tras la instalación, se crea un archivo del paquete usando los ficheros instalados. Entonces se utiliza este archivo para instalar el paquete en la máquina local, o incluso puede usarse para instalar el paquete en otras máquinas.

Este método es el usado por muchos de los administradores de paquetes que se encuentran en las distribuciones comerciales. Ejemplos de administradores de paquetes que siguen este método son RPM (que es el requerido por Linux Standard Base Specification), pkg-utils, apt de Debian y el sistema Portage de Gentoo. Una receta describiendo cómo adaptar este estilo de administración de paquetes a sistemas LFS se encuentra en http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt.

6.3.2.7. Administración basada en usuario

Este esquema, que es propio de LFS, fué desarrollado por Matthias Benkmann y está disponible en el Proyecto Hints. En este esquema, cada paquete se instala con un usuario diferente dentro de las localizaciones estándar. Los ficheros pertenecientes a un paquete se identifican fácilmente comprobando el identificador de usuario. Las características y particularidades de este método son demasiado complejas para describirlas en esta sección. Puedes consultar los detalles en la receta en http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt.