Forum

Reprise du message précédent

Si on avait mis le message en 64 langues, je pense que personne n'aurait fait l'effort de trouver sa langue préférée pour lire le message et on aurait encore plus d'utilisateurs qui auraient planté leur système en ignorant un message "IMPORTANT".

Perso même si je comprends pas l'anglais, quand après une mise à jour j'ai un message qui me dit "IMPORTANT" en lettres capitales, je suis près à faire mouliner Google Translate avant de me dire "bof ça doit pas être important".

Il y a probablement quelque chose que je ne comprends pas bien dans ce problème.

Pourquoi cette mise à jour produit-elle de nouveaux fichiers de configuration qui sont inutiles et, en plus de ça, dans le cas présent qui fichent le bazar dans le système si on les adopte ?
Les anciens fichiers étant convenables dans tous les cas, pourquoi proposer de les remplacer ?

Depuis dix ans que j'utilise Linux (Mandriva et suivantes), à chaque fois que je me suis trouvé devant ce choix j'ai conservé les anciennes versions des fichiers. Jamais je n'ai rencontré de problèmes.

À quoi peuvent servir ces nouveaux fichiers ?
J'ai cherché mais plus maintenant.

JLB

Le problème est lié au fait que ces fichiers appartiennent à des paquets (en l'occurence le paquet "setup") et utilisent la fonctionnalité de RPM la plus appropriée pour de tels fichiers, qui reste néanmoins loin d'être optimal : le type %config(noreplace).



Ce type de fichier indique à RPM que ces fichiers sont des fichiers de configuration (donc potentiellement modifiés par le système/l'utilisateur), et qu'ils ne doivent pas être remplacés lors d'une mise à jour. RPM produit donc un fichier .rpmnew avec la version "par défaut" fournie dans le nouveau paquet, et laisse l'ancienne version en place. C'est particulièrement utile dans le cas de fichiers de config pour des serveurs par exemple, où on veut que le serveur continue de fonctionner avec la config précédente, mais où il peut être pertinent de voir ce qui à changé dans la syntaxe du fichier de configuration de la nouvelle version du logiciel.



Il existe aussi le type %config (sans le "noreplace"), qui lui indique à RPM d'utiliser le nouveau fichier par défaut, mais de garder une copie du fichier de l'utilisateur en tant que fichier .rpmsave.



rpmdrake, la surcouche graphique que Mageia utilise pour gérer les RPM, a une fonctionnalité (plusieurs fois remise en question, mais toujours présente) qui notifie l'utilisateur lors de telles mises à jour, et qui propose d'examiner les différences entre les anciens fichiers et les .rpmnew, ou entre les nouveaux fichiers et les .rpmsave selon le type de %config.



En principe, c'est plutôt bien comme fonctionnalité et ça permet aux administrateurs systèmes de faire leur boulot plus facilement. rpmdrake prend en plus la peine de prévenir l'utilisateur que s'il ne sait pas quoi faire, il vaut mieux tout garder en l'état et ne pas jouer avec les fichiers .rpmnew/.rpmsave.





Le problème ici, c'est qu'il est absurde de vouloir utiliser les fichiers .rpmsave pour /etc/fstab et /etc/shadow. Néanmoins pour contourner ce problème, il faudrait que ces fichiers ne soit pas packagés du tout, pour que RPM n'agisse pas dessus lors d'une mise à jour. C'est ce qui a été discuté notamment dans le rapport de bug référencé ci-dessus, mais il est bien trop tard pour déployer un tel changement maintenant alors qu'on prépare la RC de Mageia 5.



L'autre solution, celle qui a été choisie ici, consiste à ajouter une « liste noire » de fichiers de configuration pour lesquels rpmdrake ne doit pas déployer son arsenal de "il existe des fichiers .rpmnew, que voulez-vous faire avec ?". Une mise à jour de rpmdrake a donc été préparée pour implémenter cette liste noire, et s'assurer que l'utilisateur ne sache rien de l'existence des .rpmnew. Le problème suivant était alors que suite à un bug introduit en 2009, rpmdrake ne redémarrait pas automatiquement après avoir faire une mise à jour importante telle qu'une mise à jour de lui-même, ou de RPM, meta-task, urpmi, etc.. Jusqu'à maintenant ça n'avait pas trop posé problème, mais dans ce cas précis il était vraiment important que rpmdrake redémarre pour que la « liste noire » nouvellement implémentée soit prise en compte.



Malheureusement, le changement qui fait que rpmdrake redémarre maintenant après une mise à jour critique n'est pas actif au moment où l'on fait la mise à jour de rpmdrake qui corrige ce bug, vu que la version utilisée lors de la mise à jour est la version boguée... Et pour ce dernier problème, il n'y a pas de solution. Le nouveau code est bien installé, mais c'est toujours l'ancien code qui est utilisé tant que la processus rpmdrake ouvert avant la mise à jour est actif...



D'où ce message en anglais qui indique qu'il est "IMPORTANT" de redémarrer manuellement rpmdrake avant de continuer les mises à jour. Si l'utilisateur redémarre rpmdrake, alors le patch qui implémente la liste noire est utilisé, et l'utilisateur n'est pas notifié des fichiers .rpmnew de la mise à jour de setup. Néanmoins si l'utilisateur ignore cet avertissement, fait la mise à jour de setup et là choisit sciemment d'utiliser les fichiers .rpmnew contre recommendation, il n'y a plus grand chose qu'on puisse faire.

Bonsoir,

Pour ma culture personnelle, ça veut dire quoi :
"redémarrer manuellement rpmdrake avant de continuer les mises à jour" ?
Aller dans l'interface graphique (MCC) => Gestion des logiciels => Mettre à jour votre système ?

Xuo.

Oui. Tu ferme manuellement et tu réouvres manuellement. Sous linux la prise en compte des modifications se fait depuis l'ouverture d'un programme. Par exemple une mise à jour de firefox ne se verra qu'à sa réouverture. Heureusement pour nous, il n'est pas utile de rebooter.

Par exemple oui, après avoir bien sûr fermé l'outil graphique de mise à jour. Pour faire plus simple, si peux te contenter de fermer la fenêtre et attendre la prochaine notification de mises à jour disponibles (qui devrait arriver en quelques secondes).

Merci.

Xuo.