Frederic Bothamy wrote:
[snip]
Il manque ici des infos sur la date d'exécution de la commande,
l'utilisateur, mais ça peut servir comme base de départ. Ensuite, on
peut faire un wrapper très simple pour dpkg comme ceci :
[EMAIL PROTECTED]:$ cat /usr/bin/dpkg
#!/bin/sh
/usr/bin/dpkg.old --status-fd 2 $* 2>>/var/log/dpkg.log
et de renommer auparavant bien sur l'actuel dpkg en dpkg.old (oui, je
sais, ce n'est pas propre du tout par rapport aux principes Debian). Et
on logge alors ensuite toutes les modifications des packages quel que
soit le frontal utilisé (apt, dselect ou autres).
Pour modifier le format des messages, il "suffit" d'aller modifier le
source de dpkg dans la fonction modstatdb_note de
dpkg-1.9.17/lib/dbmodify.c avec le format désiré. Pour le source de
départ, c'est :
"status: %s: %s\n", pkg->name, statusinfos[pkg->status].name
Ça peut servir comme solution de dépannage, mais certainement pas à long
terme, mais je fais confiance aux développeurs Debian pour nous sortir
une solution souple, propre et élégante (comme d'habitude).
Je reviens sur ma solution, elle présente d'autres inconvénients que je
n'avais pas vu tout de suite, en plus de ne pas être propre :
- les messages d'erreurs sont placés dans le fichier /var/log/dpkg.log
- les utilisateurs non-admin ne peuvent plus utiliser la commande pour,
par exemple, lister le contenu d'un paquet (bien que ceci puisse être
considéré comme une "feature" :-)
On peut essayer d'utiliser la sortie standard au lieu de la sortie
d'erreur comme paramètre à --status-fd, mais dans ce cas, ce sont les
messages d'installation des packages qui seront capturés par la redirection.
Conclusion : il vaut mieux attendre (ou développer) la gestion d'un
fichier de log dans dpkg (cf. la ML de debian-dpkg)
Fred