Je m'en remet aux experts d'ici après avoir posé la question sur la
liste experts de mandrake et n'ayant obtenu aucune réponse.
La source update de mdk 9.1 propose une nouvelle glibc. Je tente de
l'installer, d'abord après l'avoir téléchargée manuellement, puis,
comme ça ne passe pas, en créant une source rpm sur le ftp, mais quelque
soit, j'ai toujours un message d'erreur bizarre avec les locales-fr :
# urpmi glibc
The following packages have to be removed for others to be upgraded:
locales-2.3.1.4-6mdk.i586 (glibc == 2.3.1 non satisfait, glibc == 2.3.1 non satisfait)
locales-fr-2.3.1.4-6mdk.i586 (locales == 2.3.1.4-6mdk non satisfait)
php-manual-fr-4.3.0-2mdk.noarch (locales-fr absent)
webalizer-french-2.01.10-11mdk.i586 (locales-fr absent) (o/N) n
Je ne comprends pas.
J'ai pourtant bien les locales d'origine installées :
# rpm -qa | grep locales
locales-2.3.1.4-6mdk
locales-fr-2.3.1.4-6mdk
Et aucune mise à jour de ces locales n'est disponible.
Une mauvaise gestion des dépendances dans le package de la glibc ?
Une erreur grossière de ma part ?
Le Wed, 10 Dec 2003 11:13:26 -0400, Christophe PEREZ a écrit:
Il faudrait peut-etre essayer de ramener rpm à la version 4.0.4 mais je ne sais pas ce que ça ferait aux rpms Cooker installés.
Ben, c'est sûr, il va me proposer de les désinstaller !
Hum ! Je n'aurais peut-être pas du essayer. Je n'ai pas pensé qu'il n'y aurait pas de compatibilité descendante dans la base. Du coup : Pour satisfaire les dépendances, les paquetages suivants vont être installés (6 Mo): perl-URPM-0.81-13mdk.i586 popt-1.6.4-28mdk.i586 rpm-4.0.4-28mdk.i586 rpmtools-4.5-9mdk.i586 urpmi-4.2-34.1mdk.noarch Est-ce correct ? (O/n) o [...] Préparation... ################################################## 1:popt ################################################## 2:rpm ################################################## error: unpacking of archive failed on file /usr/lib/rpm/athlon-linux: cpio: rename failed - Is a directory 3:perl-URPM ################################################## 4:rpmtools ################################################## 5:urpmi ################################################## impossible d'accéder au fichier hdlist de « Installation CD 1 (x86) (nfs1) »; source ignorée impossible d'accéder au fichier hdlist de « Installation CD 2 (x86) (nfs2) »; source ignorée impossible d'accéder au fichier hdlist de « International CD (x86) (nfs3) »; source ignorée impossible d'accéder au fichier hdlist de « loc_contrib »; source ignorée impossible d'accéder au fichier hdlist de « loc_divers »; source ignorée impossible d'accéder au fichier hdlist de « loc_plf »; source ignorée impossible d'accéder au fichier hdlist de « loc_update »; source ignorée impossible d'accéder au fichier hdlist de « loc_src »; source ignorée impossible d'accéder au fichier hdlist de « update_source2 »; source ignorée base de données urpmi vérouillée error: %post(urpmi-4.2-34.1mdk) scriptlet failed, exit status 7
Et maintenant, plus possible d'utiliser rpm : $ rpm -qa rpmdb: /var/lib/rpm/Packages: unsupported hash version: 8 error: cannot open Packages index using db3 - Invalid argument (22)
Y a un moyen de réparer à part de restaurer des sauvegardes (qui ne seront pas nécessairement simple à mettre) ?
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 10 Dec 2003 11:13:26 -0400, Christophe PEREZ a écrit:
Il faudrait peut-etre essayer de ramener rpm à la version 4.0.4
mais je ne sais pas ce que ça ferait aux rpms Cooker installés.
Ben, c'est sûr, il va me proposer de les désinstaller !
Hum !
Je n'aurais peut-être pas du essayer.
Je n'ai pas pensé qu'il n'y aurait pas de compatibilité descendante dans
la base.
Du coup :
Pour satisfaire les dépendances, les paquetages suivants vont être installés (6 Mo):
perl-URPM-0.81-13mdk.i586
popt-1.6.4-28mdk.i586
rpm-4.0.4-28mdk.i586
rpmtools-4.5-9mdk.i586
urpmi-4.2-34.1mdk.noarch
Est-ce correct ? (O/n) o
[...]
Préparation... ##################################################
1:popt ##################################################
2:rpm ##################################################
error: unpacking of archive failed on file /usr/lib/rpm/athlon-linux: cpio: rename failed - Is a directory
3:perl-URPM ##################################################
4:rpmtools ##################################################
5:urpmi ##################################################
impossible d'accéder au fichier hdlist de « Installation CD 1 (x86) (nfs1) »; source ignorée
impossible d'accéder au fichier hdlist de « Installation CD 2 (x86) (nfs2) »; source ignorée
impossible d'accéder au fichier hdlist de « International CD (x86) (nfs3) »; source ignorée
impossible d'accéder au fichier hdlist de « loc_contrib »; source ignorée
impossible d'accéder au fichier hdlist de « loc_divers »; source ignorée
impossible d'accéder au fichier hdlist de « loc_plf »; source ignorée
impossible d'accéder au fichier hdlist de « loc_update »; source ignorée
impossible d'accéder au fichier hdlist de « loc_src »; source ignorée
impossible d'accéder au fichier hdlist de « update_source2 »; source ignorée
base de données urpmi vérouillée
error: %post(urpmi-4.2-34.1mdk) scriptlet failed, exit status 7
Et maintenant, plus possible d'utiliser rpm :
$ rpm -qa
rpmdb: /var/lib/rpm/Packages: unsupported hash version: 8
error: cannot open Packages index using db3 - Invalid argument (22)
Y a un moyen de réparer à part de restaurer des sauvegardes (qui ne
seront pas nécessairement simple à mettre) ?
Le Wed, 10 Dec 2003 11:13:26 -0400, Christophe PEREZ a écrit:
Il faudrait peut-etre essayer de ramener rpm à la version 4.0.4 mais je ne sais pas ce que ça ferait aux rpms Cooker installés.
Ben, c'est sûr, il va me proposer de les désinstaller !
Hum ! Je n'aurais peut-être pas du essayer. Je n'ai pas pensé qu'il n'y aurait pas de compatibilité descendante dans la base. Du coup : Pour satisfaire les dépendances, les paquetages suivants vont être installés (6 Mo): perl-URPM-0.81-13mdk.i586 popt-1.6.4-28mdk.i586 rpm-4.0.4-28mdk.i586 rpmtools-4.5-9mdk.i586 urpmi-4.2-34.1mdk.noarch Est-ce correct ? (O/n) o [...] Préparation... ################################################## 1:popt ################################################## 2:rpm ################################################## error: unpacking of archive failed on file /usr/lib/rpm/athlon-linux: cpio: rename failed - Is a directory 3:perl-URPM ################################################## 4:rpmtools ################################################## 5:urpmi ################################################## impossible d'accéder au fichier hdlist de « Installation CD 1 (x86) (nfs1) »; source ignorée impossible d'accéder au fichier hdlist de « Installation CD 2 (x86) (nfs2) »; source ignorée impossible d'accéder au fichier hdlist de « International CD (x86) (nfs3) »; source ignorée impossible d'accéder au fichier hdlist de « loc_contrib »; source ignorée impossible d'accéder au fichier hdlist de « loc_divers »; source ignorée impossible d'accéder au fichier hdlist de « loc_plf »; source ignorée impossible d'accéder au fichier hdlist de « loc_update »; source ignorée impossible d'accéder au fichier hdlist de « loc_src »; source ignorée impossible d'accéder au fichier hdlist de « update_source2 »; source ignorée base de données urpmi vérouillée error: %post(urpmi-4.2-34.1mdk) scriptlet failed, exit status 7
Et maintenant, plus possible d'utiliser rpm : $ rpm -qa rpmdb: /var/lib/rpm/Packages: unsupported hash version: 8 error: cannot open Packages index using db3 - Invalid argument (22)
Y a un moyen de réparer à part de restaurer des sauvegardes (qui ne seront pas nécessairement simple à mettre) ?
-- Christophe PEREZ Écrivez moi sans _faute !
Christophe PEREZ
Le Wed, 10 Dec 2003 11:28:17 -0400, Christophe PEREZ a écrit:
Y a un moyen de réparer à part de restaurer des sauvegardes (qui ne seront pas nécessairement simple à mettre) ?
Bon, j'ai restauré, je ne supportais pas de voir mon système dans cet état plus longtemps ;-) Je vais tenter (si si) une mise à jour de rpm en cooker, mais il me faut mettre à jour perl, et tous les modules dépendants, alors, je télécharge, et ça prend du temps ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 10 Dec 2003 11:28:17 -0400, Christophe PEREZ a écrit:
Y a un moyen de réparer à part de restaurer des sauvegardes (qui ne
seront pas nécessairement simple à mettre) ?
Bon, j'ai restauré, je ne supportais pas de voir mon système dans cet
état plus longtemps ;-)
Je vais tenter (si si) une mise à jour de rpm en cooker, mais il me faut
mettre à jour perl, et tous les modules dépendants, alors, je
télécharge, et ça prend du temps ;-)
Le Wed, 10 Dec 2003 11:28:17 -0400, Christophe PEREZ a écrit:
Y a un moyen de réparer à part de restaurer des sauvegardes (qui ne seront pas nécessairement simple à mettre) ?
Bon, j'ai restauré, je ne supportais pas de voir mon système dans cet état plus longtemps ;-) Je vais tenter (si si) une mise à jour de rpm en cooker, mais il me faut mettre à jour perl, et tous les modules dépendants, alors, je télécharge, et ça prend du temps ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
g.patel
On Wed, 10 Dec 2003 11:28:17 -0400, Christophe PEREZ wrote:
Je n'ai pas pensé qu'il n'y aurait pas de compatibilité descendante dans la base.
c'est le genre de chose qui parait parfaitement logique une fois qu'on a essayé...Merci, ça m'évitera peut-etre un jour une mésaventure sanglante :-)
(...)
Y a un moyen de réparer à part de restaurer des sauvegardes (qui ne seront pas nécessairement simple à mettre) ?
Télécharger les sources de rpm 4.2, compiler et installer par les méthodes de nos grand-mères. Puis utiliser ce rpm pour réinstaller le rpm de rpm 4.2.
Gérard Patel
On Wed, 10 Dec 2003 11:28:17 -0400, Christophe PEREZ
<christophe_faute@novazur.com> wrote:
Je n'ai pas pensé qu'il n'y aurait pas de compatibilité descendante dans
la base.
c'est le genre de chose qui parait parfaitement logique une
fois qu'on a essayé...Merci, ça m'évitera peut-etre un jour
une mésaventure sanglante :-)
(...)
Y a un moyen de réparer à part de restaurer des sauvegardes (qui ne
seront pas nécessairement simple à mettre) ?
Télécharger les sources de rpm 4.2, compiler et installer par
les méthodes de nos grand-mères. Puis utiliser ce rpm pour
réinstaller le rpm de rpm 4.2.
On Wed, 10 Dec 2003 11:28:17 -0400, Christophe PEREZ wrote:
Je n'ai pas pensé qu'il n'y aurait pas de compatibilité descendante dans la base.
c'est le genre de chose qui parait parfaitement logique une fois qu'on a essayé...Merci, ça m'évitera peut-etre un jour une mésaventure sanglante :-)
(...)
Y a un moyen de réparer à part de restaurer des sauvegardes (qui ne seront pas nécessairement simple à mettre) ?
Télécharger les sources de rpm 4.2, compiler et installer par les méthodes de nos grand-mères. Puis utiliser ce rpm pour réinstaller le rpm de rpm 4.2.
Gérard Patel
Christophe PEREZ
Le Wed, 10 Dec 2003 19:55:15 +0000, gerard patel a écrit:
c'est le genre de chose qui parait parfaitement logique une fois qu'on a essayé...
Ah, tu me rassures.
Merci, ça m'évitera peut-etre un jour une mésaventure sanglante :-)
Faut bien que je serve à quelque chose parfois :-)
Télécharger les sources de rpm 4.2, compiler et installer par les méthodes de nos grand-mères. Puis utiliser ce rpm pour réinstaller le rpm de rpm 4.2.
Effectivement, je n'y ai pas pensé. Mais je me demande si en faisant ça, je n'aurais pas besoin de plein de lib pour la compilation, que je ne pourrais pas installer par rpm, et du tout, obligé de passer tout à la compil.
Par contre, après être (à priori) revenu à l'état initial de mon problème (donc semi-cooker), et avoir téléchargé les rpm perl... La mise à jour ne passe pas non plus (peut-être pour les mêmes raisons, mais pas les mêmes effets) : The following packages have to be removed for others to be upgraded: inn-2.3.4-2mdk.i586 (perl == 5.8.0 non satisfait) inn-devel-2.3.4-2mdk.i586 (inn == 2.3.4 non satisfait) newsx-1.5pre-1.i386 (inn-devel absent) (o/N) n
Et ça, même en incluant les packages cooker de inn. Comprends plus bien là (non plus).
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 10 Dec 2003 19:55:15 +0000, gerard patel a écrit:
c'est le genre de chose qui parait parfaitement logique une
fois qu'on a essayé...
Ah, tu me rassures.
Merci, ça m'évitera peut-etre un jour
une mésaventure sanglante :-)
Faut bien que je serve à quelque chose parfois :-)
Télécharger les sources de rpm 4.2, compiler et installer par
les méthodes de nos grand-mères. Puis utiliser ce rpm pour
réinstaller le rpm de rpm 4.2.
Effectivement, je n'y ai pas pensé.
Mais je me demande si en faisant ça, je n'aurais pas besoin de plein de
lib pour la compilation, que je ne pourrais pas installer par rpm, et du
tout, obligé de passer tout à la compil.
Par contre, après être (à priori) revenu à l'état initial de mon
problème (donc semi-cooker), et avoir téléchargé les rpm perl...
La mise à jour ne passe pas non plus (peut-être pour les mêmes raisons,
mais pas les mêmes effets) :
The following packages have to be removed for others to be upgraded:
inn-2.3.4-2mdk.i586 (perl == 5.8.0 non satisfait)
inn-devel-2.3.4-2mdk.i586 (inn == 2.3.4 non satisfait)
newsx-1.5pre-1.i386 (inn-devel absent) (o/N) n
Et ça, même en incluant les packages cooker de inn.
Comprends plus bien là (non plus).
Le Wed, 10 Dec 2003 19:55:15 +0000, gerard patel a écrit:
c'est le genre de chose qui parait parfaitement logique une fois qu'on a essayé...
Ah, tu me rassures.
Merci, ça m'évitera peut-etre un jour une mésaventure sanglante :-)
Faut bien que je serve à quelque chose parfois :-)
Télécharger les sources de rpm 4.2, compiler et installer par les méthodes de nos grand-mères. Puis utiliser ce rpm pour réinstaller le rpm de rpm 4.2.
Effectivement, je n'y ai pas pensé. Mais je me demande si en faisant ça, je n'aurais pas besoin de plein de lib pour la compilation, que je ne pourrais pas installer par rpm, et du tout, obligé de passer tout à la compil.
Par contre, après être (à priori) revenu à l'état initial de mon problème (donc semi-cooker), et avoir téléchargé les rpm perl... La mise à jour ne passe pas non plus (peut-être pour les mêmes raisons, mais pas les mêmes effets) : The following packages have to be removed for others to be upgraded: inn-2.3.4-2mdk.i586 (perl == 5.8.0 non satisfait) inn-devel-2.3.4-2mdk.i586 (inn == 2.3.4 non satisfait) newsx-1.5pre-1.i386 (inn-devel absent) (o/N) n
Et ça, même en incluant les packages cooker de inn. Comprends plus bien là (non plus).
-- Christophe PEREZ Écrivez moi sans _faute !
g.patel
On Wed, 10 Dec 2003 23:44:26 -0400, Christophe PEREZ wrote:
Mais je me demande si en faisant ça, je n'aurais pas besoin de plein de lib pour la compilation, que je ne pourrais pas installer par rpm, et du tout, obligé de passer tout à la compil.
peut-être.
Par contre, après être (à priori) revenu à l'état initial de mon problème (donc semi-cooker), et avoir téléchargé les rpm perl... La mise à jour ne passe pas non plus (peut-être pour les mêmes raisons,
non, pas pour les mêmes raisons.
mais pas les mêmes effets) : The following packages have to be removed for others to be upgraded: inn-2.3.4-2mdk.i586 (perl == 5.8.0 non satisfait)
C'est un sous-produit du téléchargement des rpm perls. C'est très chatouilleux de mettre à jour perl sur une Mandrake, du fait que tous les utilitaires ou presque reposent sur Perl. Il y a eu plusieurs cafouillages pendant la période qui a précédé la 9.2.
Gérard Patel
On Wed, 10 Dec 2003 23:44:26 -0400, Christophe PEREZ
<christophe_faute@novazur.com> wrote:
Mais je me demande si en faisant ça, je n'aurais pas besoin de plein de
lib pour la compilation, que je ne pourrais pas installer par rpm, et du
tout, obligé de passer tout à la compil.
peut-être.
Par contre, après être (à priori) revenu à l'état initial de mon
problème (donc semi-cooker), et avoir téléchargé les rpm perl...
La mise à jour ne passe pas non plus (peut-être pour les mêmes raisons,
non, pas pour les mêmes raisons.
mais pas les mêmes effets) :
The following packages have to be removed for others to be upgraded:
inn-2.3.4-2mdk.i586 (perl == 5.8.0 non satisfait)
C'est un sous-produit du téléchargement des rpm perls.
C'est très chatouilleux de mettre à jour perl sur une Mandrake,
du fait que tous les utilitaires ou presque reposent sur Perl. Il y a
eu plusieurs cafouillages pendant la période qui a précédé la 9.2.
On Wed, 10 Dec 2003 23:44:26 -0400, Christophe PEREZ wrote:
Mais je me demande si en faisant ça, je n'aurais pas besoin de plein de lib pour la compilation, que je ne pourrais pas installer par rpm, et du tout, obligé de passer tout à la compil.
peut-être.
Par contre, après être (à priori) revenu à l'état initial de mon problème (donc semi-cooker), et avoir téléchargé les rpm perl... La mise à jour ne passe pas non plus (peut-être pour les mêmes raisons,
non, pas pour les mêmes raisons.
mais pas les mêmes effets) : The following packages have to be removed for others to be upgraded: inn-2.3.4-2mdk.i586 (perl == 5.8.0 non satisfait)
C'est un sous-produit du téléchargement des rpm perls. C'est très chatouilleux de mettre à jour perl sur une Mandrake, du fait que tous les utilitaires ou presque reposent sur Perl. Il y a eu plusieurs cafouillages pendant la période qui a précédé la 9.2.
Gérard Patel
Christophe PEREZ
Le Thu, 11 Dec 2003 08:25:50 +0000, gerard patel a écrit:
C'est un sous-produit du téléchargement des rpm perls. C'est très chatouilleux de mettre à jour perl sur une Mandrake, du fait que tous les utilitaires ou presque reposent sur Perl. Il y a eu plusieurs cafouillages pendant la période qui a précédé la 9.2.
Il semblerait là que le package inn nécessite =perl 5.8.1, et pas > perl 5.8.1 C'est bizarre quand même non ?
-- Christophe PEREZ Écrivez moi sans _faute !
Le Thu, 11 Dec 2003 08:25:50 +0000, gerard patel a écrit:
C'est un sous-produit du téléchargement des rpm perls.
C'est très chatouilleux de mettre à jour perl sur une Mandrake,
du fait que tous les utilitaires ou presque reposent sur Perl. Il y a
eu plusieurs cafouillages pendant la période qui a précédé la 9.2.
Il semblerait là que le package inn nécessite =perl 5.8.1, et pas > perl 5.8.1
C'est bizarre quand même non ?
Le Thu, 11 Dec 2003 08:25:50 +0000, gerard patel a écrit:
C'est un sous-produit du téléchargement des rpm perls. C'est très chatouilleux de mettre à jour perl sur une Mandrake, du fait que tous les utilitaires ou presque reposent sur Perl. Il y a eu plusieurs cafouillages pendant la période qui a précédé la 9.2.
Il semblerait là que le package inn nécessite =perl 5.8.1, et pas > perl 5.8.1 C'est bizarre quand même non ?
-- Christophe PEREZ Écrivez moi sans _faute !
g.patel
On Thu, 11 Dec 2003 10:32:05 -0400, Christophe PEREZ wrote:
Il semblerait là que le package inn nécessite =perl 5.8.1, et pas > >perl 5.8.1
ah ? il me semble que le requires liste la 5.8.0 : inn-2.3.4-2mdk.i586 (perl == 5.8.0 non satisfait)
ça a l'air bizarroide, je pense que les dernières lignes ne comptent pas puisque la première ligne (2:5.8.2) indique une version plus récente. Par contre il lui faut la 5.8.2, ni plus, ni moins (ainsi que le numéro de série 2). Perl est très chatouilleux sur la compatibilité apparemment.
Gérard Patel
On Thu, 11 Dec 2003 10:32:05 -0400, Christophe PEREZ
<christophe_faute@novazur.com> wrote:
Il semblerait là que le package inn nécessite =perl 5.8.1, et pas > >perl 5.8.1
ah ? il me semble que le requires liste la 5.8.0 :
inn-2.3.4-2mdk.i586 (perl == 5.8.0 non satisfait)
ça a l'air bizarroide, je pense que les dernières lignes ne
comptent pas puisque la première ligne (2:5.8.2) indique
une version plus récente. Par contre il lui faut la 5.8.2, ni
plus, ni moins (ainsi que le numéro de série 2). Perl est
très chatouilleux sur la compatibilité apparemment.
ça a l'air bizarroide, je pense que les dernières lignes ne comptent pas puisque la première ligne (2:5.8.2) indique une version plus récente. Par contre il lui faut la 5.8.2, ni plus, ni moins (ainsi que le numéro de série 2). Perl est très chatouilleux sur la compatibilité apparemment.
Gérard Patel
Christophe PEREZ
Le Thu, 11 Dec 2003 21:22:22 +0000, gerard patel a écrit:
ah ? il me semble que le requires liste la 5.8.0 : inn-2.3.4-2mdk.i586 (perl == 5.8.0 non satisfait)
Oui.
[ gerard]# rpm -q --requires inn-2.3.5-7mdk
Ah ben il a été mis depuis hier alors ! J'ai récupéré hier le 2.3.5-6 ! :-)
ça a l'air bizarroide, je pense que les dernières lignes ne comptent pas puisque la première ligne (2:5.8.2) indique une version plus récente. Par contre il lui faut la 5.8.2, ni plus, ni moins (ainsi que le numéro de série 2).
C'est bien ce que je disais, mais ma version nécessitait le 5.8.1, ni plus ni moins, donc le perl 5.8.2 ne passait pas. Je vais télécharger pour voir.
Perl est très chatouilleux sur la compatibilité apparemment.
Oui, mais là, c'est plutôt le package inn qui est en cause non ?
-- Christophe PEREZ Écrivez moi sans _faute !
Le Thu, 11 Dec 2003 21:22:22 +0000, gerard patel a écrit:
ah ? il me semble que le requires liste la 5.8.0 :
inn-2.3.4-2mdk.i586 (perl == 5.8.0 non satisfait)
Ah ben il a été mis depuis hier alors !
J'ai récupéré hier le 2.3.5-6 ! :-)
ça a l'air bizarroide, je pense que les dernières lignes ne
comptent pas puisque la première ligne (2:5.8.2) indique
une version plus récente. Par contre il lui faut la 5.8.2, ni
plus, ni moins (ainsi que le numéro de série 2).
C'est bien ce que je disais, mais ma version nécessitait le 5.8.1, ni
plus ni moins, donc le perl 5.8.2 ne passait pas.
Je vais télécharger pour voir.
Perl est
très chatouilleux sur la compatibilité apparemment.
Oui, mais là, c'est plutôt le package inn qui est en cause non ?
Le Thu, 11 Dec 2003 21:22:22 +0000, gerard patel a écrit:
ah ? il me semble que le requires liste la 5.8.0 : inn-2.3.4-2mdk.i586 (perl == 5.8.0 non satisfait)
Oui.
[ gerard]# rpm -q --requires inn-2.3.5-7mdk
Ah ben il a été mis depuis hier alors ! J'ai récupéré hier le 2.3.5-6 ! :-)
ça a l'air bizarroide, je pense que les dernières lignes ne comptent pas puisque la première ligne (2:5.8.2) indique une version plus récente. Par contre il lui faut la 5.8.2, ni plus, ni moins (ainsi que le numéro de série 2).
C'est bien ce que je disais, mais ma version nécessitait le 5.8.1, ni plus ni moins, donc le perl 5.8.2 ne passait pas. Je vais télécharger pour voir.
Perl est très chatouilleux sur la compatibilité apparemment.
Oui, mais là, c'est plutôt le package inn qui est en cause non ?
-- Christophe PEREZ Écrivez moi sans _faute !
Christophe PEREZ
Le Thu, 11 Dec 2003 21:41:23 -0400, Christophe PEREZ a écrit:
C'est bien ce que je disais, mais ma version nécessitait le 5.8.1, ni plus ni moins, donc le perl 5.8.2 ne passait pas. Je vais télécharger pour voir.
Fait. Perl 5.8.2, inn, urpmi, rpm mis à jour (cooker), mais la glibc standard (non cooker) ne passe toujours pas pour les mêmes raisons. Bon, j'abandonne là, c'était juste pour tenir au courant ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
Le Thu, 11 Dec 2003 21:41:23 -0400, Christophe PEREZ a écrit:
C'est bien ce que je disais, mais ma version nécessitait le 5.8.1, ni
plus ni moins, donc le perl 5.8.2 ne passait pas.
Je vais télécharger pour voir.
Fait.
Perl 5.8.2, inn, urpmi, rpm mis à jour (cooker), mais la glibc standard
(non cooker) ne passe toujours pas pour les mêmes raisons. Bon,
j'abandonne là, c'était juste pour tenir au courant ;-)
Le Thu, 11 Dec 2003 21:41:23 -0400, Christophe PEREZ a écrit:
C'est bien ce que je disais, mais ma version nécessitait le 5.8.1, ni plus ni moins, donc le perl 5.8.2 ne passait pas. Je vais télécharger pour voir.
Fait. Perl 5.8.2, inn, urpmi, rpm mis à jour (cooker), mais la glibc standard (non cooker) ne passe toujours pas pour les mêmes raisons. Bon, j'abandonne là, c'était juste pour tenir au courant ;-)
