Afin de pouvoir signaler un bug, j'aimerais le reproduire sur une RH récente (là j'ai pu sur une 9 mais le bugzilla de RH ne propose pas de signaler des bugs dessus)
Donc si quelqu'un pouvait, sur une fedora par exemple,
J'ai souvent pensé à l'expérience suivante :
- faire un paquet deb ou rpm qui fait juste un hit sur un site web à l'installation
- dire sur LinuxFr "Hé, regardez ce truc là" avec un compte créé quelques jours avant
- compter le nombre de machine root-kitable sans effort
Tu viens de mettre mon idée en pratique, ou bien tu cherches vraiment un bug ? :)
Regardes le contenu du rpm, il a 0 fichier et 0 scripts dedans :-)
C'est un pb quand le logiciel a un + dans le numéro de version, ce qui a déjà été le cas par exemple de mldonkey. Ca posait un pb sur Mandrake vu que urpme mldonkey appelait la lib rpm en lui demandant de supprimer mldonkey-laversioncomplete et la librpm repondait que c'était pas installé. Il fallait donc désinstaller à la main avec rpm -e sans préciser la version ou faire d'abord une update vers une version sans +...
D'après les tests, si urpme ajoute \ devant le plus ca passera, mais bon j'aimerais le signaler à RH que ce soit corrigé si possible...
J'avais voulu le signaler à l'époque mais j'avais pas trouvé de RH :-) Je retente en demandant ici, ca devrait être plus efficace.
[root@vaio-fx502 ~]# yum remove test-1+2-1 'test-1\+2-1' test
Gathering header information file(s) from server(s)
Server: Fedora Core 1 - i386 - Base
Server: Fedora Core 1 - i386 - Released Updates
Finding updated packages
Downloading needed headers
Erase: No matches for test-1+2-1
Erase: No matches for test-1\+2-1
Resolving dependencies
Dependencies resolved
I will do the following:
[erase: test 1+2-1.i586]
Is this ok [y/N]:
Tout marche avec rpm :
[test@ici test]$ rpm -q test
test-1+2-1
[test@ici test]$ rpm -q test-1+2
test-1+2-1
[test@ici test]$ rpm -q test-1+2-1
test-1+2-1
"yum remove test-1+2" ou "yum remove test-1+2-1" ne marche pas. "yum remove test" marche.
Idem pour "yum info".
Tu peux créer un bugzilla pour FC2 (composant yum).
Mais c'est peut-être un bug rpm-python. J'en ai vu un passer récemment sur la mailing devel (spécifique avec python 2.3.3 (FC2) alors que ça marche avec python 2.3.4).
Idéalement il faudrait mettre à jour vers rawhide.
Tu trouveras des gens avec des machines en rawhide sur la mailing test. Ce n'est pas mon cas actuellement.
Si tu ne reproduit pas ce "petit" bug avec rawhide (ou FC3T1), il est possible qu'il soit ignoré.
D'après ce qui est dit plus haut rpm 4.3.1 a l'air OK, je vais donc attendre (Mandrake est en 4.2.2 je crois et je ne sais pas trop d'ou vient ce 4.3.1, ftp://ftp.rpm.org/pub/rpm/dist/(...) s'arrete en 4.2.1...)
# Ah et aussi celui là :
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
# Expérience intéressante
Posté par Wawet76 . Évalué à 2.
J'ai souvent pensé à l'expérience suivante :
- faire un paquet deb ou rpm qui fait juste un hit sur un site web à l'installation
- dire sur LinuxFr "Hé, regardez ce truc là" avec un compte créé quelques jours avant
- compter le nombre de machine root-kitable sans effort
Tu viens de mettre mon idée en pratique, ou bien tu cherches vraiment un bug ? :)
[^] # Re: Expérience intéressante
Posté par Pascal Terjan (site web personnel) . Évalué à 4.
C'est un pb quand le logiciel a un + dans le numéro de version, ce qui a déjà été le cas par exemple de mldonkey. Ca posait un pb sur Mandrake vu que urpme mldonkey appelait la lib rpm en lui demandant de supprimer mldonkey-laversioncomplete et la librpm repondait que c'était pas installé. Il fallait donc désinstaller à la main avec rpm -e sans préciser la version ou faire d'abord une update vers une version sans +...
D'après les tests, si urpme ajoute \ devant le plus ca passera, mais bon j'aimerais le signaler à RH que ce soit corrigé si possible...
J'avais voulu le signaler à l'époque mais j'avais pas trouvé de RH :-) Je retente en demandant ici, ca devrait être plus efficace.
# Re: Bug avec rpm
Posté par gros_rouge . Évalué à 3.
Voici la sortie pour une FC1 (désolé, j'ai pas plus récent) :
[fabrice@vaio-fx502 ~]$ rpm -q test test-1+2-1 'test-1\+2-1' rpm
test-1+2-1
le paquetage test-1+2-1 n'est pas installé
test-1+2-1
rpm-4.2.1-0.30
Fab.
[^] # Re: Bug avec rpm
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
[^] # Re: Bug avec rpm
Posté par Laurent Simon . Évalué à 1.
[lolo@localhost Packages]$ rpm -q test test-1+2-1 'test-1\+2-1'
test-1+2-1
test-1+2-1
test-1+2-1
avec : RPM version 4.3.1
[^] # Re: Bug avec rpm
Posté par gros_rouge . Évalué à 2.
[root@vaio-fx502 ~]# yum remove test-1+2-1 'test-1\+2-1' test
Gathering header information file(s) from server(s)
Server: Fedora Core 1 - i386 - Base
Server: Fedora Core 1 - i386 - Released Updates
Finding updated packages
Downloading needed headers
Erase: No matches for test-1+2-1
Erase: No matches for test-1\+2-1
Resolving dependencies
Dependencies resolved
I will do the following:
[erase: test 1+2-1.i586]
Is this ok [y/N]:
yum-2.0.5-1 sur FC1, toujours.
Fab.
[^] # Re: Bug avec rpm
Posté par Laurent Simon . Évalué à 1.
Effectivement, j'ai la même erreur que toi, avec yum-2.0.7-3.1 (FC2); même problème avec apt (apt 0.5.15cnc6).
Mais c'est ok avec rpm -e test-1+2-1 .
# Essai sur FC2
Posté par 007 . Évalué à 1.
[test@ici test]$ rpm -q test
test-1+2-1
[test@ici test]$ rpm -q test-1+2
test-1+2-1
[test@ici test]$ rpm -q test-1+2-1
test-1+2-1
"yum remove test-1+2" ou "yum remove test-1+2-1" ne marche pas. "yum remove test" marche.
Idem pour "yum info".
Tu peux créer un bugzilla pour FC2 (composant yum).
Mais c'est peut-être un bug rpm-python. J'en ai vu un passer récemment sur la mailing devel (spécifique avec python 2.3.3 (FC2) alors que ça marche avec python 2.3.4).
Idéalement il faudrait mettre à jour vers rawhide.
Tu trouveras des gens avec des machines en rawhide sur la mailing test. Ce n'est pas mon cas actuellement.
Si tu ne reproduit pas ce "petit" bug avec rawhide (ou FC3T1), il est possible qu'il soit ignoré.
[^] # Re: Essai sur FC2
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
[^] # Re: Essai sur FC2
Posté par 007 . Évalué à 1.
Dans les src.rpm il y a toujours le tar.gz d'origine. Sans les patch Red Hat (peu nombreux puisque c'est Red Hat qui fait le développement).
Donc les sources du 4.3.1 sont aussi ici :
http://fr2.rpmfind.net/linux/fedora/core/2/SRPMS/rpm-4.3.1-0.3.src.(...)
Rawhide est à 4.3.2 :
http://fr2.rpmfind.net/linux/fedora/core/development/SRPMS/(...)
Je te garantis que le CVS à la dernière version.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.