Journal [ATTENTION] Upgrade Mandrake Cooker à risque

Posté par (page perso) .
Tags : aucun
0
18
sept.
2004
Bonjour journal,

Je m'adresse aux utilisateurs de Mandrake Cooker ou 10.1rc1 et de kdm qui ont fait ou compte faire une mise à jour bientôt.

La mise à jour du package kdebase-kdm-config-file est foireuse et va vous détruire votre variable PATH en n'y ajoutant pas /bin, /usr/bin, /usr/local/bin entre autre donc plus de ls, plus de rm, plus grand chose en fait :)

En fait le fichier /etc/kde/kdm/kdmrc est mal mis à jour et donc un fichier /etc/kde/kdm/kdmrc.rpmnew est créé.
Il vous faudra donc faire un mv /etc/kde/kdm/kdmrc.rpmnew /etc/kde/kdm/kdmrc pou que tout revienne dans l'ordre.

Le bug est référencé ici : http://qa.mandrakesoft.com/show_bug.cgi?id=11560(...)

Si un employé Mandrake traine dans le coin, pourrait-il nous renseigné sur la façon de faire pour qu'urpmi propose de fusionner les fichiers en conflit comme le fait rpmdrake ? Ca éviterait ce genre de déboires.
Oui rpm nous prévient qu'il a trouvé un conflit mais je regarde rarement mes logs de mise à jour de paquets :)
Ca serait bien qu'urpmi le fasse mais en le proposant à la fin car souvent on met à jour et on va faire un tour alors si ça bloque tous les 10 packages ça va être lourd.

Faire suivre la proposition à kivabien chez Mandrake :)

Merci,

Franck
  • # hmmm

    Posté par (page perso) . Évalué à 2.

    En principe, un rpmnew est crée pendant l'upgrade si tu as modifié le fichier d'origine(ici via kcontrol).
    Un rpmsave est créer pendant le supression pour la meme raison.

    Mais la, je vois mal comment ca aurait pu changer ton PATH? urpmi(enfin rpm) ne touche en aucun cas ton fichier de conf, il ne fusionne rien du tout.

    Le seul script kde que je connaisse et qui influe sur le PATH, c'est startkde.
    • [^] # Re: hmmm

      Posté par (page perso) . Évalué à 3.

      Va voir le bugreport pour l'explication du PATH.

      Sinon pour les .rpmsave et .rpmnew un corse me souffle dans l'oreille que (en parlant du package rpm):
      "ca depend du tag dans le spec ( %config(replace) ou %config(noreplace) )"

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: hmmm

        Posté par . Évalué à 5.

        > Sinon pour les .rpmsave et .rpmnew un corse me souffle dans l'oreille que ...

        Et tu entends toujours de cette oreille ? Non parce que il ne reste pas grand chose de certaines habitations soufflées par des corses /o\

        « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

      • [^] # Re: hmmm

        Posté par (page perso) . Évalué à 2.

        Oops :) J'avais pas compris ton explication :) Je croyais que une fois sous kde ton PATH etait pas bon...

        Oui j'avoue, j'ai pas lu ton bug report, c'est mal... :(

        Et tiens, j'apprend un truc pour l'histoire du rpmsave/new :)
        Merci houpla ;)
        • [^] # Re: hmmm

          Posté par . Évalué à 2.

          > l'histoire du rpmsave/new

          Faut noter que ça utilise les md5sum stockés dans la base rpm et le rpm à installer. Si les deux md5sum sont indentiques, le fichier n'est pas touché et il n'y a pas de rpmsave/new. Idem si le fichier a été modifié. C'est utilisé _uniquement_ pour les fichiers de configuration.
        • [^] # Re: hmmm

          Posté par . Évalué à 1.

          C'est pas mal effectivement.
          Par contre une fois je me suis retrouvé avec des rpmnew et des rpmsave mais plus les fichiers de conf. Ca peut être très génant pour certains fichiers.

          Et quelqu'un connaitrait-il l'équivalent du gentooien etc-update, qui fusionne automatiquement les fichiers très légèrement modifiés, et qui liste ceux restant et permet de les traiter (affichage de diff pour décider de ce qu'on fait, possibilité de modifier un des fichiers...)?
  • # Hum

    Posté par (page perso) . Évalué à 2.

    Je sais pas trop ce qui serait le plus simple...

    Peut etre installer etc-update et le lancer après chaque mise à jour
    Sinon
    rpm -qalc | grep / | while read i; do if [ -f "$i.rpmnew" ]; then echo "$i" ; fi  ; done
    ou plutôt juste sur ceux qui viennent d'être mis à jour :-) Et ensuite faire les merge à la main...
    La solution top serait de grader le fichier de conf du rpm installé quelque part, pour pouvoir faire un patch avec les modifs de l'utilisateur et ensuite essayer de l'appliquer au nouveau (ou même afficher cette liste de modifs à l'utilisateur, qu'il puisse merger plus facilement)

    Ca se passe comment dans rpmdrake ? il affiche les contenus ? propose d'éditer ? d'ecraser ?
    • [^] # Re: Hum

      Posté par (page perso) . Évalué à 2.

      Je me rappelle plus trop comment ça marche dans rpmdrake car je le trouve inergonomqie donc je ne l'utilise plus.
      Mais dans mes souvenirs, il proposait de choisir entre avant et après en affichant le diff. Je sais plus si il proposait d'éditer ou de merger à la main. Quelqu'un aurait la réponse ?

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

  • # Ca aurait fait...

    Posté par (page perso) . Évalué à 4.

    Un jolie thread dans les forum :)
    • [^] # Re: Ca aurait fait...

      Posté par . Évalué à 2.

      Ca tombe bien : http://linuxfr.org/forums/14/3603.html(...)
      Cela dit, la première page pour un but dans une version de développement, c'est beaucoup...
      • [^] # Re: Ca aurait fait...

        Posté par (page perso) . Évalué à 2.

        Vous commencez à nous les pomper menu avec vos "Ca serait mieux dans les forums", "Ca vaut pas une première page",....

        J'ai évalué que c'est info pouvait éviter à un plus grand nombre de d'avoir les mêmes déboires que j'ai eu et aussi aurait pû réduire le nombre de mail de personne affolée sur les mailing-list de Mandrake ou sur IRC. Je l'ai donc mis à l'endroit le plus visible.

        Qui plus est ce système de "gestion des droits" m'a autorisé à poster un journal en première page et donc si il s'avère que ça ne valait pas un journal ni d'être en première oage alors que ce système soit virer définitivement. Mais personnellement cette politique de repasser les journaux dans les forums je trouve ça réellement très très chiant. Si vous vous voulez modérer les journaux alors faites le jusqu'au bout comme pour les news.

        Si tu n'es pas content propose toi comme modéro ou relecteur. Je viens justement de libérer ma place.

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

  • # sans le path c'est chiant , mais c'est pas la mort

    Posté par . Évalué à 2.

    il suffit de taper les nom complets
  • # PVM

    Posté par (page perso) . Évalué à 2.

    Tiens ca me fait penser que mon PATH était complètement explosé sous cooker la semaine dernière, c'était du à PVM qui se permet de patcher comme un grand /etc/bashrc (ou /etc/profile je sais plus), en explosant ce qui a été fait avant. Et le comble c'est que lorsqu'on enlève le RPM bien sûr il ne nettoie pas ses saletés dans /etc/bashrc. Et je ne sais même pas ce qui avait tiré pvm puisque "rpm -e pvm" a fonctionné sans dépendance..

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.