La commande pour reconstruire la base des rpm est Incroyable !

Et elle marche du tonnerre.

Je l'ai utilisé en voulant mettre à jour Yum, et elle est très pratique !

😉
Bon de retour du boulot je me lance...
Un rpm -e eog-2.20.1-1.fc8.i386me donne:
[root@71 ~]# rpm -e eog-2.20.1-1.fc8.i386
The generated cache was invalid.
erreur: %postun(eog-2.20.1-1.fc8.i386) scriptlet failed, exit status 1
Après un rpm --rebuilddb le resultat est le même

Maintenant quand je fait une correction des erreurs par smart j'ai ce message d'erreur:
man-1.6e-3.fc7 requiert diffutils
rpmdevtools-6.4-1.fc8 requiert diffutils
rpm-build-4.4.2.2-7.fc8 requiert diffutils
grub-0.97-19 requiert /usr/bin/cmp
redhat-lsb-3.1-19.fc8 requiert /usr/bin/cmp
gtk-doc-1.8-2.fc7 requiert /usr/bin/cmp
redhat-lsb-3.1-19.fc8 requiert /usr/bin/diff
policycoreutils-2.0.31-15.fc8 requiert /usr/bin/diff
PyOpenGL-3.0.0-0.4.a6.fc8 requiert python-setuptools
hal-0.5.10-1.fc8 requiert libvolume_id.so.0
udev-116-3.fc8 requiert libvolume_id.so.0
hal-0.5.10-1.fc8 requiert libvolume_id >= 089-1
Et un yum remove eog-2.20.1-1.fc8.i386 me donne le même résultat que précédemment...

C'est le message d'erreur de smart qui m'inquiète...Si je re-démarre mon ordi va-t-il le faire ou vais-je voir droit à des problèmes?...
Je pense que cela a à voir avec le dépôt rpm-db (d'ailleurs qu'est ce que c'est que ce dépôt? )
Quand je désactive ce dépôt dans smart je n'ai plus ce problème...
Et quand j'active ce dépôt il m'affiche des mises a jours... Mais je ne sais si il faut les faire
Par contre même en enlevant le dépôt rpm-db j'ai toujours le problème pour enlever par exemple eog-2.20.1-1.fc8.i386
[root@71 ~]# rpm -e eog-2.20.1-1.fc8.i386
The generated cache was invalid.
erreur: %postun(eog-2.20.1-1.fc8.i386) scriptlet failed, exit status 1
Pourquoi le cache est invalide? et que faire pour y remédier?
rpm-db est en fait la base des rpm installés. Si tu le désactives, la résolution des dépendances ne peut être assurée (cache invalide).

Commence sans doute par faire la mise à jour de eog (vers la version 2.20.2-1) puis reprends les tests smart. Accessoirement, vérifie que diffutils est bien installé (en version 2.8.1-19).
Bon j'ai ré-activé rpm-db, eog-2.20.2-1 et diffutils-2.8.1-19 sont déjà installés et c'est toujours le même problème... cela n'est peut-être pas important vu que ma F8 fonctionne très bien...et j'ai l'impression que je suis le seul à voir ce problème
bonjour en cherchant sur internet j'ai trouvé une solution : désinstallé chaque paquets qui posent problèmes avec l 'option --noscripts, par exemple:
[root@132 ~]# rpm -e --noscripts eog-2.20.1-1.fc8.i386
Cela supprime bien les paquets concernés et un "Corrigé les problèmes" dans smart ne me donne plus rien à corriger
Mais cela n'est pas vraiment une solution, car entre temps il y a eu un update de system-config-firewall et donc je me suis retrouvé avec les deux version installées... un rpm -e --noscripts system-config-firewall-1.0.8-3.fc8.noarch m' enlevé l'ancienne version mais je ne me vois pas faire cela à chaque update de n'importe quel paquets
22 jours plus tard
chepioq wrote:Bon j'ai ré-activé rpm-db, eog-2.20.2-1 et diffutils-2.8.1-19 sont déjà installés et c'est toujours le même problème... cela n'est peut-être pas important vu que ma F8 fonctionne très bien...et j'ai l'impression que je suis le seul à voir ce problème
J'ai les même problèmes que toi. Depuis une mise à jour récente de yum, des messages "The generated cache was invalid." apparaissent dans yum.log :
Dec 12 08:23:25 Updated: yum - 3.2.8-2.fc8.noarch
Dec 12 08:23:26 The generated cache was invalid.
Cette erreur est apparu en particulier en essayant de désinstaller les paquets : "compiz-gnome", "ccsm", et "system-config-firewall". J'ai fait plusieur fois "rpm --rebuilddb", "yum clean dbcache", "yum clean all", mais cela ne change rien : les paquets en question restent impossibles à désinstaller avec yum ou pirut. Message d'erreur de Smart :
The generated cache was invalid.
error: %postun(system-config-firewall-1.0.11-1.fc8.noarch) scriptlet failed, exit status 1
Avec la commande "rpm -e --noscripts" la désinstallation fonctionne, mais ce n'est pas une solution satisfaisante.
Je pense avoir trouvé l'origine du problème : https://bugzilla.redhat.com/show_bug.cgi?id=378231#c7

J'avais installé http://www.autopackage.org/ il y a quelques jours.
Ce programme place des PNG, entre autre dans /usr/share/icons/hicolor/
Ces icônes font planter gtk-update-icon-cache , qui est appelé par certains scripts de dé-installation.
En conséquence, ces dé-installations restaient bloquées.

Après avoir supprimé autopackage, tous ces problèmes ont disparu.
merci de ta réponse, mais j'ai changé d'ordi entre temps...Et je n'ai plus ce problème... Mais je me souviens que j'avais aussi installé autopackage, chose que je n'ai pas encore fait, et que je me garderai bien de faire...merci pour l'info
un mois plus tard
S'il en est encore (moi, pas plus tard qu'aujourd'hui) confrontés à ce problème de conflit entre yum et autopackage, aller dans /usr/bin/ et désinstaller autopackage en lançant son propre installateur/desinstallateur de programme. Il s'autosupprime ainsi et tout redevient normal dans yum et autres.