Quelle est la méthode pour passer de Lenny à Squeeze ?

Merci pour vos réponses et pour les source.list.

Cependant plusieurs réactions/questions :

[quote=“Taureau89_9”]

aptitude update

apt-get upgrade

apt-get dist-upgrade

(et pas aptitude pour les deux derniers)[/quote]

Uh ??? oO Et pourquoi donc ?
Je croyais que c’était f… à coup sûr le bronx dans ses paquets/dépendances que de mélanger allègrement les 2 commandes ? Y a t’il une subtilité qui m’échappe ?

Là par contre, j’avoue ne pas avoir eu ce choix là :

C’est sur un serveur web en prod (je n’utilise pas de version desktop) que je me suis rendu compte qu’un truc clochait.
J’ai fait une petite upgrade de maintenance hier matin comme je le fais fréquement, or, ce faisant, j’ai eu un comportement plus que bizarre de certains paquets qui sans prévenir, se sont retrouvés orphelins de leurs dépendances et/ou se sont supprimés sauvagement.

Et de préférence, des paquets cruciaux tant qu’à faire (genre php5, php5-gd, libapache2-mod-php5 et php5-mysql qui ont la bonne idée de se supprimer d’un serveur web en prod pour régler un conflit de dépendances… je vous laisse imaginer ma déconvenue oO)

En fait c’est à ce moment là, quand j’ai vu quelles version des dépendances étaient demandées, que j’ai compris qu’une nouvelle dist devait être sur les rails et un petit tour ici me l’a confirmé.

Tout ça pour dire que les emmerdes en très gros, j’ai difficilement pu faire sans. MAJ forcée en quelque sorte, pour pouvoir rétablir la bonne marche de mon système. Sinon mon serveur, je l’aurais bien laissé sous Lenny vu que ca tournait bien et, mon expérience d’Ubuntu m’ayant trop souvent montré les problèmes classiques et un peu inévitables qui surviennent à chaque dist-upgrade, si j’avais pu l’éviter sur un serveur de prod, je l’aurais fait, en attendant justement que tout se stabilise et qu’il y ait un peu moins de bugs reportés à droite à gauche.

Bon, j’ajoute à la décharge de Debian que c’est très probablement de ma faute, j’aurais peut être pas dû jouer avec les dépots backports et dotdeb sur un serveur de prod. Ca m’apprendra :mrgreen:

[quote=“lol”]Il est donc préférable de faire dist-upgrade avant upgrade, non ?
Je ne vois pas l’intérêt de risquer la casse avec l’upgrade alors que dist-upgrade (qui est la même chose que safe-upgrade) permet justement de l’éviter ?[/quote]
Non, c’est tout le contraire. upgrade correspond à safe-upgrade alors que dist-upgrade correspond à full-upgrade. Seul dist-upgrade peut supprimer des paquets précédemment installés. Un upgrade après un dist-upgrade ne servirait à rien car ce dernier fait non seulement tout ce que fait le premier mais aussi des choses que le premier ne fait pas.

Ok, j’ai raconté de carabistouilles… Merci de la précision, c’est noté.

La commande update ne fait que la mise à jour de la liste des paquets disponibles pour chaque dépôt. A ma connaissance il n’y a pas de différence entre apt-get et aptitude à ce niveau, sauf qu’aptitude est plus lourd et donc plus lent sur les machines peu puissantes. Donc j’utilise toujours apt-get pour l’update, même si j’utilise aptitude pour l’upgrade.
Les différences entre apt-get et aptitude concernent (ou concernaient) d’autres commandes comme install, remove (pour la gestion des paquets installés automatiquement par dépendance) et dist-upgrade/full-upgrade (pour la stratégie de résolution des conflits).

Les paquets installés orphelins, c’est normal s’ils n’existent plus dans la nouvelle version. Par contre un simple upgrade ne devrait pas supprimer de paquets. Et tout ceci n’a pu arriver que si sources.list faisait référence à “stable” et non “lenny”.

Petite précision : quand je aprle de mélanger les 2 commandes, je faisait référence à aptitude VS apt-get :wink:

Quand au reste, non mon source.list faisait bien référence à lenny et non stable.

Ceci dit, la lecture de vos posts sur les différences et similitude entre les safe- full- et dist- m’a permis de comprendre un peu mieux d’où venait ma carafe.

Je pensait innocement que safe-upgrade n’était autre qu’un simulateur (une sorte de preview de ce qui allait être fait sur le systeme pendant la MAJ en gros…) comme sur gentoo en quelque sorte et du coup, je ne faisais que des full-upgrade…

Alors je ne comprends pas comment un dist-upgrade ou full-upgrade a pu provoquer un conflit de dépendance. Les dépendances d’une version stable ne changent qu’exceptionnellement, et en tout cas certainement pas à l’occasion de la sortie de la version stable suivante.

Le simulateur pour apt-get et aptitude c’est l’option -n.

Moi non plus mais bon, en même temps plus de quoi fouetter un chat, mon système est de nouveau “up & running”

Juste quelques bricoles à re-régler mais rien de grave :wink:

Oui et non, dans la mesure où les mises à jour ne sont pas installées automatiquement et ou on conserve donc la possibilité de faire ce qu’on veut.

Là aussi oui et non. Car les notes de publication, pas toujours faciles à interpréter pour des non avertis, semblent indiquer l’étape intermédiaire comme une précaution et que le changement de noyau peut-être fait automatiquement par l’étape finale, et c’est pour ça que j’ai squeezé (c’est le cas de le dire :033 ).
Et comme je me retrouve en 2.6.32 au lieu de 2.6.26, je pense que c’est ce qui s’est passé et au final je n’ai loupé à priori aucune étape :083

[quote=“man apt-get”]-s, --simulate, --just-print, --dry-run, --recon, --no-act
Pas d’action ; simule les événements qui devraient se produire sans effectuer de
changement réel sur le système. Élément de configuration : APT::Get::Simulate.

       Lorsque la simulation est effectuée par un utilisateur sans privilège, le verrouillage
       (Debug::NoLocking) sera désactivé automatiquement. Une mention explicite indiquant qu'il
       s'agit d'une simple simulation sera affichée si l'option
       APT::Get::Show-User-Simulation-Note est activée (elle est active par défaut). Ni la
       désactivation du verrou ni l'affichage de la mention de simulation ne seront déclenchées
       si la commande est lancée par l'utilisateur root (pour qui il n'est pas jugé utile
       qu'apt-get envoie de telles notifications).

       La simulation affiche une série de lignes représentant chacune une opération de dpkg,
       Configure (Conf), Remove (Remv), Unpack (Inst). Des crochets encadrent des paquets
       endommagés et des crochets n'encadrant rien indiquent que les dommages n'ont aucune
       conséquence (rare).[/quote]

Par contre je ne trouve pas d’option -n ni dans le man aptitude, ni dans le man apt-get.

En même temps à quoi bon simuler à part à tuer l’amour :033

Ben non. Par exemple, on perd la possibilité de ne faire que les mises à jour de sécurité. Au prochain upgrade, c’est tout ou rien.

@ youki :
Effectivement j’ai dû confondre avec une autre commande.