[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mise à jour de ce soir de testing



1113072761 comput unicum (Sat, 09 Apr 2005 20:52:41 +0200),
Arnaud a écrit :
>
> Je reviens sur le sujet car si ça ne m'embête pas trop de voir kde 
> disparaître, j'aimerais bien comprendre le pourquoi du comment de ce 
> genre de comportement du gestionnaire de paquets.
> Je n'ai pas regardé les dépendances des autres paquets de la mise à jour
> , chose que je vais faire de ce pas, mais un paquet aurait il besoin de 
> désinstaller kde pour se mettre à jour ? bizarre, pour moi en tout cas !

Ça s'explique : un paquet A est mis à jour, mais un paquet B dépend de la
version précédente (avec un = sur la version, et un conflit sur > (et
aussi sur <, en général)). Ce paquet B est alors marqué à enlever, et,
avec lui, tous les paquets qui en dépendent.

Si ce paquet B se trouve être une bibliothèque de base de kde, tout kde
saute.

La solution : bloquer la mise à jour du paquet A en attendant que B soit
reconstruit avec une dépendance modifiée.

Tout est donc assez logique mais ce qui me gêne dans ce comportement,
c'est que, par défaut, les outils apt ont cette « mauvaise » réaction,
alors qu'il devrait être possible de donner le choix ou de prévenir avant
de faire toute cette modification. (Oui, je sais, on peut revenir en
arrière ou bloquer à la main, mais il faut en général resélectionner tous
les paquets déselectionnés.)

Je croyais que la distinction « installé à la main » - « installé
automatiquement suite à une dépendance » qu'aptitude permet de faire
empêchait justement ce genre de problèmes...

> Les éclaircissements des gurus debian seront les bienvenus.

Pour kde, ce sont des kourous. Et d'ailleurs : à mon kourou, coucou.

-- 
Sylvain Sauvage



Reply to: