Forum debian-fr.org

Ça veut dire que ce paquet est incompatible avec tous ceux listés, par exemple tu ne peux pas avoir libc6-i386 (= 2.11.3-2) et fakechroot (< 2.9-1.1) installés en même temps sur ta machine.


Y'a un truc que je comprends pas : tu dis que ta machine est en 32 bits, mais ce paquet n'est disponible que pour l'architecture AMD64 : http://packages.debian.org/search?keywords=libc6-i386
T'es sûr que t'es bien sur une machine/installation 32 bits ??
De toutes façons, la question à résoudre c'est : pourquoi ça a été installé ? Tu as des programmes 32 bits à faire tourner (probablement des trucs qui ne viennent pas des dépôts, sinon soit ils seraient en 64 bits soit ils dépendraient de cette lib) ?

_________________
testing/unstable (amd64) sous KDE4
github/syam44 - De la bonne manière de poser les questions - Wiki debian-fr
Just because you're paranoid doesn't mean they aren't after you. -- J.Heller

Tu as raison, c'est moi qui déconne, mon serveur est en 64 mais comme j'ai l'habitude de le "visiter" en ssh via mon P4, en 32 bits, lui, j'ai fait la confonderie absurditionnelle
Grosse fatigation le Ricardo

EDIT :
J'en déduis donc que ta réponse est : purge ?

_________________
.
"L'action est plus efficace que la polémique, mais plus rare." Ricardo (1936-20..)
http://rictux.fr

Tout nettoyé, serveur propre

_________________
.
"L'action est plus efficace que la polémique, mais plus rare." Ricardo (1936-20..)
http://rictux.fr

Question suite à mon fil sur kate/kwrite :
En faisant comme tu le dis plus haut :
aptitude unmarkauto ~i
on marque en manuel TOUS les paquets qui sont installés ?
Si oui, quand on fait ensuite un <fix-aptitude-dependencies>, ça replace exactement tout comme avant automatiquement, sans se retaper à la main un par un ?

_________________
.
"L'action est plus efficace que la polémique, mais plus rare." Ricardo (1936-20..)
http://rictux.fr

C'est exactement ça. L'idée c'est qu'en marquant tous les paquets en manuel, quand tu supprimes un paquet alors seul le strict minimum est supprimé avec (dans le cas de kwrite, les méta-paquets qui dépendent de kwrite), et comme il n'y a plus aucun paquet en automatique tu ne risques pas de supprimer "par accident" tout KDE. Une fois la suppression effectuée, lancer le script se chargera de remettre au mieux l'état automatique des paquets restants (clairement ça ne pourra pas être exactement comme avant puisque certaines dépendances auront changé dû à la suppression de kwrite et des méta-paquets, mais c'est tout à fait normal). Si la suppression de kwrite laisse des libs orphelines, elles seront détectées par deborphan et tu pourras les supprimer manuellement.

_________________
testing/unstable (amd64) sous KDE4
github/syam44 - De la bonne manière de poser les questions - Wiki debian-fr
Just because you're paranoid doesn't mean they aren't after you. -- J.Heller

Ok, je vais faire ça.
je vais supprimer les deux : kwrite et Kate car j'ai le même problème avec les deux. Ensuite, je ne réinstallerai que kate, ce qui sera suffisant.

_________________
.
"L'action est plus efficace que la polémique, mais plus rare." Ricardo (1936-20..)
http://rictux.fr

Ben il est têtu
J'ai eu beau placer tout en manuel, quand je veux ensuite purger kwrite, il me propose encore de virer les autres. J'ai refusé et la seule proposition qui envoie c'est de rétrograder de version.






MOI, JE VEUX LE VIRER

_________________
.
"L'action est plus efficace que la polémique, mais plus rare." Ricardo (1936-20..)
http://rictux.fr

Évidemment qu'il veut virer ces 3 méta-paquets en plus de kwrite :
- kde-baseapps dépend de kwrite
- kde-plasma-desktop dépend de kde-baseapps
- kde-standard dépend de kde-plasma-desktop

Si tu veux supprimer kwrite tu ne peux pas faire autrement, de toutes façons ça ne porte pas à conséquence c'est que des méta-paquets.
La différence en passant tout en manuel c'est que la suppression de ces 3 méta-paquets ne va pas provoquer la suppression de KDE, alors que si tu n'avais pas fait unmarkauto ~i y'a tout KDE qui partait à cause des dépendances automatiques.

_________________
testing/unstable (amd64) sous KDE4
github/syam44 - De la bonne manière de poser les questions - Wiki debian-fr
Just because you're paranoid doesn't mean they aren't after you. -- J.Heller

Je n'avais pas compris comme ça.
Je fais.
à demain

_________________
.
"L'action est plus efficace que la polémique, mais plus rare." Ricardo (1936-20..)
http://rictux.fr

Je viens de remarquer quelque chose, à propos des paquets qui apparaissent en "id", au premier lancement de fix-aptitude-dependencies.

Premier lancement d'aptitude safe-upgrade = paquets à installer + paquets à enlever + paquets à mettre à jour + 1 bug signalé par apt-listbugs.
aptitude hold nom_du_paquet_buggué
Second lancement d'aptitude safe-upgrade = paquets à installer + paquets à mettre à jour.

La liste des paquets à enlever a disparu.
J'ignore si elle reviendra avec la disparition du bug précédemment signalé mais, en attendant, les paquets qui devaient être enlevés à l'origine et ne l'ont pas été se retrouvent en "id".

Chercher à comprendre...

_________________
Chercher à comprendre, c'est commencer à désobéir.

1/ moi qui suis fainéant, je fais # aptitude upgrade au lieu de # aptitude safe-upgrade (résultat : idem)
2/ moi qui suis fainéant (merci Hollande et son anaphore ), je fais 'p' à la demande d'accord "Y, n, q ?"au lieu de # aptitude hold paquets. Seule contrainte : il faut vouloir épingler TOUS les paquets reconnus bogués par apt-listbugs.
Pour la liste des paquets disparus, je ne vois pas.

_________________
.
"L'action est plus efficace que la polémique, mais plus rare." Ricardo (1936-20..)
http://rictux.fr

Comprendre totalement comment aptitude gère ses p'tites affaires et nos mises à jour... hmmm... p'être pas, finalement.

Je me demandais d'où sortaient ces paquets "id" jusqu'à ce que je repère un nom déjà vu dans la liste des paquets à supprimer et qui ne l'étaient finalement pas, après mon aptitude hold.

Au lieu de aptitude keep '!~v', j'ai suivi ma logique en passant directement à aptitude purge les_paquets_devenus_id.

Et pour ma part de fainéantise, j'utilise le pavé fléché de mon clavier, pour parcourir l'historique des commandes.

_________________
Chercher à comprendre, c'est commencer à désobéir.

Tu peux aussi chercher les résidus pour t'occuper
$ aptitude searh ~c

_________________
.
"L'action est plus efficace que la polémique, mais plus rare." Ricardo (1936-20..)
http://rictux.fr

Salut,

J'ai utilisé le script, et ça a bien fonctionné.
Comment on fait pour désinstaller ce script ? Il suffit de supprimer les 2 fichiers dans /etc et celui dans /usr/sbin ?

_________________
sid/amd64
gnome3/gnome-shell

Ravi de l'entendre (ou de le lire, plutôt).


Tout à fait.
Pour être précis, ces deux fichiers :

• /etc/apt/fix-aptitude-dependencies.conf
• /usr/local/sbin/fix-aptitude-dependencies

_________________
testing/unstable (amd64) sous KDE4
github/syam44 - De la bonne manière de poser les questions - Wiki debian-fr
Just because you're paranoid doesn't mean they aren't after you. -- J.Heller

Merci encore pour le partage

_________________
sid/amd64
gnome3/gnome-shell

Quelle idée de vouloir le désinstaller !
Même si tu ne t'en sers pas souvent, ça peut être utile de temps en temps d'en envoyer un p'tit coup.
Ce n'est pas pour la place que prennent ces deux fichier que tu gagneras beaucoup, il me semble.

_________________
.
"L'action est plus efficace que la polémique, mais plus rare." Ricardo (1936-20..)
http://rictux.fr

Oui c'est vrai, je suis d'accord mais c'était plus par curiosité qu'autre chose. Je ne l'ai même pas désinstallé d'ailleurs...

_________________
sid/amd64
gnome3/gnome-shell

_________________
.
"L'action est plus efficace que la polémique, mais plus rare." Ricardo (1936-20..)
http://rictux.fr

Suite à un retour de bug (une sombre histoire concernant deborphan et l'affichage des libs orphelines) j'ai corrigé le script, la mise à jour est disponible toujours au même endroit.
Merci ricardo.

_________________
testing/unstable (amd64) sous KDE4
github/syam44 - De la bonne manière de poser les questions - Wiki debian-fr
Just because you're paranoid doesn't mean they aren't after you. -- J.Heller

Salut,

La solution utilisée par certains scripts est d'aller voir eux-mêmes si une version améliorée n'est pas disponible et de prévenir l'utilisateur ou de se mettre à jour (solution discutable, j'en convient).

_________________
Debian 3.9-2.slh.2-aptosid (3.9.12) GT520 > nvidia 319.17 ==> Intel (I5) ~3GHz
http://aptosid-fr.org/

Voilà une excellente idée.
C'est d'ailleurs une honte que Syam ne l'inclue pas dans ces scripts

_________________
.
"L'action est plus efficace que la polémique, mais plus rare." Ricardo (1936-20..)
http://rictux.fr

Le script de Syam, je l'ai essayé, mais avec ma SID de plusieurs années il veut rien savoir... trop de dépendances croisées!
J'ai d'ailleurs cessé d'essayer aptitude tout court...

_________________
GO Compréhensif...
SID 3.8-etc...-aptosid-amd64 && Xfce 4.10
"Pastbin" / "service d'hébergement d'images" Visitez et Participez au wiki du forum!

J'avais une vieille Sid aussi et j'ai réussi à le faire ... tout seul
Maintenant, j'en passe un coup chaque jour ou presque, ainsi, s'il y a un problème, c'est vite règlé.

_________________
.
"L'action est plus efficace que la polémique, mais plus rare." Ricardo (1936-20..)
http://rictux.fr

J'y ai déjà pensé. Malheureusement je n'ai toujours pas trouvé de méthode correcte pour qu'un script shell se mette à jour lui-même, je bute sur un point particulier. Je sais, faudrait que je me penche dessus...

_________________
testing/unstable (amd64) sous KDE4
github/syam44 - De la bonne manière de poser les questions - Wiki debian-fr
Just because you're paranoid doesn't mean they aren't after you. -- J.Heller