# [PORTAGE] Scripts de inventario/gestion ebuilds (¿solucion?)

## ackward

Despues de mi pelea semestral con mi gentoo, la ultima "sandbox (cannot run C compiled programs)", he pensando que ya es hora de hacer limpieza y someterle a una cura de adelgazamiento. 

El "emerge -e world" es inviable... el "-vuD world" es de horas/dias. Una solucion es reinstalar pero ha aguantado desde marzo del 2004, sigue funcionando optimamente (fusion,wow, glibc2.7, gcc4.2.2,...), y la verdad... le he cogido cariño    :Laughing: 

La pregunta: ¿Conoceis scripts para gestionar/inventariar el portage? No hablo del gentoolkit, eix y demas...no sacar una simple lista de paquetes instalados sino algo mas elaborado.

Pj: Grafica del arbol de dependencias de paquetes instalados para identificar hojas.

Dado un directorio (pj /usr/bin) a partir de la mac de los ficheros obtener el listado de paquetes a los que pertenecen ordenados por fecha de utilizacion (para identificar paquetes que no se usen).

Historico de actualizaciones? registro de emerges. Se puede meter portage y su bbdd en algun vcs? 

Bueno, cogeis la idea.  :Smile: Last edited by ackward on Wed Jan 09, 2008 9:19 pm; edited 2 times in total

----------

## i92guboj

Si estás buscando una sofisticada herramienta creo que no encontrarás nada.

 *ackward wrote:*   

> 
> 
> Pj: Grafica del arbol de dependencias de paquetes instalados para identificar hojas.
> 
> 

 

No se exactamente a qué te refieres. Si lo que quieres es hacer limpieza, el método más sencillo es coger tu /var/lib/portage/world, (previo backup) y borrar todas las líneas que no sepas que son. En ese fichero solo debería haber cosas que tu emerjas a mano normalmente. No debería haber ni una librería, porque a no ser que te dediques al desarrollo de programas, las librerías solo se instalan como dependencias.

Tras limpiar eso un poco y hacer un emerge --ask --depclean tu sistema debería estar considerablemente más limpio. Tras eso, puedes recurrir a uno de los scripts que hay por ahí para buscar basura, aunque yo personalmente no los he usado nunca porque no me fío de una utilidad así a no ser que la haya escrito yo. Si buscas "cruft" en los foros seguramente salga algo (recuerdo una llamado findcruft, pero seguramente haya muchos, eso si, bastante anticuados y no muy seguros).

 *Quote:*   

> Dado un directorio (pj /usr/bin) a partir de la mac de los ficheros obtener el listado de paquetes a los que pertenecen ordenados por fecha de utilizacion (para identificar paquetes que no se usen).

 

No hace falta magia alguna para esto:

```

#Para listar el paquete al que pertenece cada archivo

for i in /bin/*; do equery b "$i"; done

```

En cuanto a los paquetes que no se usen, yo me centraría en el fichero world. Registrar tu sistema a la caza de archivos no es una tarea viable para un sistema de escritorio, debe haber más o menos medio millón de archivos en un sistema gentoo linux (así a ojo).

 *Quote:*   

> 
> 
> Historico de actualizaciones? registro de emerges. Se puede meter portage y su bbdd en algun vcs? 
> 
> Bueno, cogeis la idea. 

 

Todos los logs están en /var/log, incluyendo el de emerge. Lo exhaustivo que sea y hasta donde abarque depende de como lo configuraras en su día, si usas logrotate, si usas algún tipo de limpiador para tus logs, etc etc etc etc.

----------

## ackward

 *i92guboj wrote:*   

> 
> 
> No se exactamente a qué te refieres. Si lo que quieres es hacer limpieza, el método más sencillo es coger tu /var/lib/portage/world, (previo backup) y borrar todas las líneas que no sepas que son. 
> 
> Tras limpiar eso un poco y hacer un emerge --ask --depclean tu sistema debería estar considerablemente más limpio. 

 

Sip, este era evidentemente el paso principal pero despues de tanto tiempo de uso sin control (en casa del herrero...) quiero asegurarme sin hacerme viejo. 

Se han hecho instalaciones por partes con lo que en world hay mas dependencias que ficheros finales, ha servido de desarrollo a aplicaciones java, python, perl, mono e incluso c... estuvo funcionando con e17 (ebuilds que se bajaban las fuentes de cvs...), tuvo xgl incluso antes de que empezaran a organizarlo en overlays... funciona pero no se como.   :Laughing: 

Buscaba algo que me permitiese ver clusteres de aplicaciones instaladas, grupos independientes que permitan una primera poda rapida y agresiva y luego ya mas manual o individualizado el proceso, pero bueno todo es ponerse y andar con cuidado.

Los logs por concepto no sirven, no organizan informacion simplemente almacenan. Hacen falta parsers y no es optimo. 

He pensado que la solucion al registro de emerges es versionar /var/db/pkg en git. Por ahora manualmente aunque no deberia ser muy complicado integrarlo en los postscripts de los ebuilds para que haga adds automaticamente y guarde como log, info del ebuild. Quiza sea pasarse... no va a haber ramas, ni vueltas atras... aunque si se le suma quickpkg... se podria tener un metodo para instalar una serie de paquetes y si no te gusta el resultado volver a la situacion original...

----------

## i92guboj

 *ackward wrote:*   

> 
> 
> He pensado que la solucion al registro de emerges es versionar /var/db/pkg en git. Por ahora manualmente aunque no deberia ser muy complicado integrarlo en los postscripts de los ebuilds para que haga adds automaticamente y guarde como log, info del ebuild. Quiza sea pasarse... no va a haber ramas, ni vueltas atras... aunque si se le suma quickpkg... se podria tener un metodo para instalar una serie de paquetes y si no te gusta el resultado volver a la situacion original...

 

Bueno, todo esto es viable, aunque no puedo calcular a ojo el trabajo que haría falta.

Si lo que quieres es comprar las listas de paquetes de antes y de después, una solución casera podría servir (aunque por supuesto no de forma retrospectiva). Un sencillo listado de los paquetes lo tienes con:

```

cd /var/db/pkg; for i in */*; do echo $i; done > ~/list-pre.txt

```

Un sencillo método sería ejecutar ese comando antes de instalar nada, luego, tras finalizar nuestros experimentos haríamos:

```

cd /var/db/pkg; for i in */*; do echo $i; done > ~/list-post.txt

```

Con un diff entre ambos y un poco de bash scripting podriamos generar unas bonitas líneas "emerge -C <loquesea>" que nos llevarían al estado anterior. No se si lo que tienes en mente es algo así.

----------

## ackward

 *i92guboj wrote:*   

> 
> 
> Con un diff entre ambos y un poco de bash scripting podriamos generar unas bonitas líneas "emerge -C <loquesea>" que nos llevarían al estado anterior. No se si lo que tienes en mente es algo así.

 

Necesitas cambiar el chip, piensa a lo grande   :Cool: 

No pienses solo en un pc de escritorio, otro dia quiza sea un servidor, quiza sean mas, quiza haya mas de un administrador, quiza no sea gentoo ni linux sino solaris. 

El uso de vcs lo llevo mirando bastante tiempo porque los ficheros /etc deben ser auditados y poder ver sus diferencias, ni cvs ni svn me convencieron para esa funcionalidad pero git si lo esta haciendo y de ahi a versionar el pkg solo hay un paso mas.

Tan sencillo como despues de un emerge (ya creado un repositorio inicial):

```

# git commit -a

```

Ventajas:

 * Historico en condiciones y completo. Pj, podrias de un fichero cualquiera saber desde que version lo tienes instalado y cuando se instalo por primera vez ya que el CONTENT esta versionado tambien (esto es una exigencia SoX pj).

* Identificacion por usuario, si hay varios adminsitradores a partir del uid original para identificar los cambios. 

* Si ademas por cada paquete que se compila se guarda su binario y se versiona tambien no solo puedes tirar atras, es que puedes hacer las pruebas en otras maquinas. Montar un sistema distribuicion push de paquetes gentoo.

Estas que se me hayan ocurrido en los ultimos minutos pero fijo que hay mas utilidades que pueden salir.

----------

## gringo

 *Quote:*   

> El uso de vcs lo llevo mirando bastante tiempo porque los ficheros /etc deben ser auditados y poder ver sus diferencias, ni cvs ni svn me convencieron para esa funcionalidad pero git si lo esta haciendo y de ahi a versionar el pkg solo hay un paso mas. 

 

imagino que ya lo sabrás pero dispatch.conf puede mantener diffs de los archivos modificados, aunque no se aproxima a lo que estás buscando, no es un vcs ni de lejos, y no creo que haya algo como lo que buscas. De hecho estaba siguiendo el hilo para ver si alguien sabía algo mas del tema  :Wink: 

Puedes probar si quieres con paludis o con udept que al menos en lo que es en información de dependencias son un pelín mas completos, pero al igual que las demás herramientas parsean logs y la info en /var.

saluetes

----------

## ekz

 *ackward wrote:*   

>  aunque si se le suma quickpkg... se podria tener un metodo para instalar una serie de paquetes y si no te gusta el resultado volver a la situacion original...

 

Muy interesante lo que planteas, solo quería añadir/decir/comentar que con demerge se podría hacer lo que dices en este parrafo:

```
app-portage/demerge

     Available versions:  0.043 0.044 ~0.045

     Installed versions:  0.044 

     Homepage:            http://download.mpsna.de/opensource/demerge/

     Description:         demerge - revert to previous installation states
```

```
 demerge version 0.044 (using PortageXS-0.02.07)

 --comment [ comment ]       : Add comment to state for your convenience.

 --do                        : Do not ask user to confirm actions - just do it.

 --dir [ directory ]         : Select directory to store/get demerge data.

 -h, --help                  : Show this help.

 -k, --usepkg                : Pass -k to emerge so that binary packages

                             : will be used when available. When enabling this

                             : option demerge will also create binpkgs of

                             : packages before removing them.

                             : (Note: Currently --usepkg is not useflag aware. So

                             : no matter what useflags were set in the system-state

                             : portage will install the binpkg as is.)

 -C, --nocolor               : Turn off colors.

 --record                    : Records which packages are installed

                             : on this system.

 --restore [ timestamp ]     : Restores previous recorded system-state of the given

                             : timestamp.

 --restore-previous          : Restores previous recorded system-state.

 --wipe [ timestamp ]        : Remove all/given system-states.

 --wipe-older [ timestamp ]  : Remove all recorded system-states that are

                             : older than the given timestamp.

```

Saludos

----------

## ackward

He estado trasteando un poco en el curro (solaris + hg) y hay algunos problemas relacionados con el hecho de que no se versionan los permisos (usuario, grupos, roles, pero tambien los rwx, suids, sticky bit, etc...), problemas de seguridad. 

Por ese mismo motivo se estan currando etckeeper

 *Quote:*   

> etckeeper is a collection of tools to let /etc be stored in a git or mercurial repository. It hooks into apt (and other package managers) to automatically commit changes made to /etc during package upgrades. It uses metastore to track file metadata that revison control systems do not normally support, but that is important for /etc, such as the permissions of /etc/shadow.

 

Originalmente para debian y apt, se han currado dos cosas: 

1) ebuilds para gentoo e integracion via hooks con paludis ( emerge actualiza el repositorio automaticamente).

2) conociendo que gentoo guarda en texto su informacion de pkts instalados, la posibilidad de especificar mas de un  directorio a versionar (es decir, no solo /etc).

No lo he probado todavia porque no he usado nunca paludis y quiero aprender y conocer sus riesgos antes de empezar a usarlo (acabare probandolo en una imagen virtual...) pero mas o menos es un camino claro por donde seguir. Ademas de lo poco que he visto de paludis, ya mehe fijado en sus hooks que pueden dar mucha juego para funcionalidad extra.

Ah, una cosa mas. En solaris para controlar si hay cambios he estado usando el bart (basic auditing report tool) una especie de aide o tripwire, pero en linux tanto git como mercurial tienen soporte/plugin inotify. Esto serviria para controlar los cambios en /etc que realizan manualmente otras personas y/o demonios/aplicaciones que modifican ficheros de configuracion (estos ultimos el brebe tutorial de etckeeper recomienda mandarlos al .gitignore).

----------

