Forum Linux.debian/ubuntu Mise à jour/Installation Steam Debian Conflit de paquets

Posté par . Licence CC by-sa.
0
21
oct.
2018

Bonjour à tous !
J'ai un soucis lors de la mise à jour de Steam, qui me demande d'installer les paquets libgl1-mesa-dri:i386 et libgl1-mesa-glx:i386, que je ne peux installer.
Voila le résultat quand j'essaye d'installer tout ça:

user@debian:~$ sudo apt install libgl1-mesa-dri:i386 libgl1-mesa-glx:i386
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Certains paquets ne peuvent être installés. Ceci peut signifier
que vous avez demandé l'impossible, ou bien, si vous utilisez
la distribution unstable, que certains paquets n'ont pas encore
été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation : 
Les paquets suivants contiennent des dépendances non satisfaites :
libgl1-mesa-dri:i386 : Dépend: libdrm-amdgpu1:i386 (>= 2.4.63) mais ne sera pas installé
                       Dépend: libdrm-intel1:i386 (>= 2.4.48) mais ne sera pas installé
                       Dépend: libdrm-nouveau2:i386 (>= 2.4.66) mais ne sera pas installé
                       Dépend: libdrm-radeon1:i386 (>= 2.4.31) mais ne sera pas installé
                       Dépend: libdrm2:i386 (>= 2.4.66) mais ne sera pas installé
                       Dépend: libelf1:i386 (>= 0.142) mais ne sera pas installé
                       Dépend: libllvm3.9:i386 (>= 1:3.9.1-6~) mais ne sera pas installé
libgl1-mesa-glx:i386 : Dépend: libdrm2:i386 (>= 2.4.66) mais ne sera pas installé
                       Dépend: libglapi-mesa:i386 (= 13.0.6-1+b2) mais ne sera pas installé
                       Dépend: libx11-xcb1:i386 mais ne sera pas installé
                       Dépend: libxcb-dri2-0:i386 (>= 1.8) mais ne sera pas installé
                       Dépend: libxcb-dri3-0:i386 mais ne sera pas installé
                       Dépend: libxcb-glx0:i386 (>= 1.8) mais ne sera pas installé
                       Dépend: libxcb-present0:i386 mais ne sera pas installé
                       Dépend: libxcb-sync1:i386 mais ne sera pas installé
                       Dépend: libxshmfence1:i386 mais ne sera pas installé
E: Impossible de corriger les problèmes, des paquets défectueux sont en mode « garder en l'état ».

Quand j'essaye avec aptitude, il veut m'enlever quelques 600 paquets donc pas possible (si vous voulez la liste n’hésitez pas, je ne l'ai juste pas mise la car trop long).
Je sais que ce sujet à déjà été traité de nombreuses fois mais aucunes des solutions proposées n'a résolu mon soucis…

Voila quelques infos utiles:
Je suis sous Debian 9 (Stretch) avec KDE.
Contenu de /proc/version :

Linux version 4.16.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-19)) #1 SMP Debian 4.16.12-1 (2018-05-27)

Mon système est à jour (update, upgrade, dist-upgrade, autoremove, clean et autoclean).
Contenu de /etc/apt/sources.list:

deb http://deb.debian.org/debian/ stretch main contrib non-free
deb http://security.debian.org/ stretch/updates main contrib non-free
deb http://deb.debian.org/debian/ stretch-updates main contrib non-free

Contenu de /etc/apt/sources.list.d/:

playonlinux.list       skype-stable.list       steam.list       teamviewer.list.save  vivaldi.list.save playonlinux.list.save  skype-stable.list.save  teamviewer.list  vivaldi.list

J'ai déjà essayé de désinstaller (purge) et de réinstaller, via les sources et le deb, rien n'a fonctionné.

Merci d'avance.

  • # sources.list.d

    Posté par . Évalué à 1 (+0/-0).

    Sans trop y croire : peut-être au niveau de ton fichier de sources steam.list ? Steam est déjà dans les dépôts officiels, j'essayerais en le supprimant.
    Il n'est fait mention d'aucun conflit pour justifier le fait que les dépendances ne seront pas installées ?

    • [^] # Re: sources.list.d

      Posté par . Évalué à 1 (+0/-0).

      Ici le steam.list est la car j'avais tenté l'install depuis le .deb, mais depuis les depots (en supprimant le steam.list) et c'est pareil, sauf que le soucis survient direct à l'installation, et plus au lancement.
      Pour ce qui est des conflits, j'ai essayé d'approfondir le truc, et a chaque fois je tombe sur des conflits, et quand j'essaye avec aptitude, il me propose de dégager plus de 600 paquets donc je suppose que c'est en conflit avec une lib essentielle.

  • # tu as fait des modifications à la main ?

    Posté par . Évalué à 3 (+1/-0).

    le message semble dire que tu as bloqués les mises à jour de certains paquets

    E: Impossible de corriger les problèmes, des paquets défectueux sont en mode « garder en l'état ».

    du coup le gestionnaire de paquet ne veut plus les mettre à jour de maniere automatique
    il faut donc debloquer ces paquets, au risque de casser autre chose.

    • [^] # Re: tu as fait des modifications à la main ?

      Posté par . Évalué à 1 (+0/-0).

      Euh, je ne me souviens pas d'avoir réglé cette option pour certains paquets et pour avoir regardé plus précisément quelles libs posent problème, elles bloquent un peu toutes, donc c'est étrange.
      Et ce message apparaît a chaque conflit et jamais je n'ai eu de soucis qui venait de là, donc c'est vrai que je ne me suis pas penché la dessus, mais je suis preneur d'une idée pour fouiller cette piste !

      • [^] # Re: tu as fait des modifications à la main ?

        Posté par . Évalué à 1 (+0/-0).

        Voici un petit lien vers une doc Debian que gardais en marque-page avec un paragraphe qui indique comment vérifier si tu as des paquets gelés.
        Par contre ça n'indique que le dégel au cas par cas, pas de commande pour débloquer tous les paquets.

        Par curiosité, ton système est une installation de Stretch ou une dist-upgrade depuis Jessie ?

  • # est-tu bien en multiarch ?

    Posté par (page perso) . Évalué à 1 (+0/-0).

    A priori steam n'est dispo que pour les archi i386, est-ce que tu as bien activé le multiarch sur ta machine ?

    Essaye:
    $ sudo dpkg --add-architecture i386
    $ sudo apt install libgl1-mesa-dri:i386 libgl1-mesa-glx:i386

  • # sans titre

    Posté par . Évalué à 1 (+0/-0).

    Est-ce que tu utilises le pilote Nvidia pour ta carte graphique ? si c'est le cas, aucune raison d'installer les paquets mesa.

    Ensuite, c'est étrange d'avoir un "vieux" noyau 4.16 et un sources.list qui n'indique pas le dépot backport.

    Enfin, tu indiques que tu as testé des solutions mais lesquelles ?

    • [^] # Re: sans titre

      Posté par . Évalué à 1 (+0/-0).

      Mince, je viens de me rendre compte que j'ai oublié de préciser ça dans mon post, voila mon matos :
      C'est un laptop Lenovo, avec un processeur Intel core I5, un SSD 120 GO et un HDD de 1TO, et 4GO de ram.
      Je n'ai pas de carte graphique donc j'utilise (normalement) les drivers pour l'IGP de mon proco.

      Ensuite, c'est étrange d'avoir un "vieux" noyau 4.16 et un sources.list qui n'indique pas le dépot backport.

      Ah ? Je devrais donc ajouter les dépôts backport à mon sources.list ?

      Enfin, tu indiques que tu as testé des solutions mais lesquelles ?

      Je pourrais pas toutes les lister, mais pas mal de celles sur lequel on tombe en cherchant sur internet des problèmes qui ressemblent aux miens, comme le sudo dpkg --add-architecture i386, la création de certains liens symboliques (ou je n'avais pas les fichier à lier), ou l'installation de certains paquets (impossible à installer ou non trouvés en général).

      • [^] # Re: sans titre

        Posté par . Évalué à 1 (+0/-0).

        Edit: Après ajout des dépôts backports et mise à jour, j'ai retenté une installation de steam via les dépôts officiels, et voila le résultat.

        user@debian:~$ sudo apt install steam
        Lecture des listes de paquets... Fait
        Construction de l'arbre des dépendances       
        Lecture des informations d'état... Fait
        Certains paquets ne peuvent être installés. Ceci peut signifier
        que vous avez demandé l'impossible, ou bien, si vous utilisez
        la distribution unstable, que certains paquets n'ont pas encore
        été créés ou ne sont pas sortis d'Incoming.
        L'information suivante devrait vous aider à résoudre la situation : 
        
        Les paquets suivants contiennent des dépendances non satisfaites :
         steam:i386 : Dépend: libudev1:i386 mais ne sera pas installé
                      Dépend: libgl1-mesa-dri:i386 mais ne sera pas installé
                      Dépend: libgl1-mesa-glx:i386 mais ne sera pas installé
                      Recommande: zenity:i386
                      Recommande: libxss1:i386 mais ne sera pas installé
        E: Impossible de corriger les problèmes, des paquets défectueux sont en mode « garder en l'état ».
        

        J'ai par la suite pu installer le paquet libudev1:i386 avec sudo apt-get -t stretch-backports install libudev1:i386 mais pas libgl1-mesa-dri:i386 ni libgl1-mesa-glx:i386, toujours a cause des soucis de dépendances, respectivement

        Les paquets suivants contiennent des dépendances non satisfaites :
         libgl1-mesa-glx:i386 : Dépend: libgl1:i386
                                Dépend: libglx-mesa0:i386 mais ne sera pas installé
        

        Pour libgl1-mesa-glx:i386 et

        Les paquets suivants contiennent des dépendances non satisfaites :
         libgl1-mesa-dri:i386 : Dépend: libdrm-amdgpu1:i386 (>= 2.4.90) mais ne sera pas installé
                                Dépend: libdrm-intel1:i386 (>= 2.4.38) mais ne sera pas installé
                                Dépend: libdrm-nouveau2:i386 (>= 2.4.66) mais ne sera pas installé
                                Dépend: libdrm-radeon1:i386 (>= 2.4.31) mais ne sera pas installé
                                Dépend: libdrm2:i386 (>= 2.4.75) mais ne sera pas installé
                                Dépend: libelf1:i386 (>= 0.142) mais ne sera pas installé
                                Dépend: libllvm6.0:i386 (>= 1:6.0~svn298832-1~) mais ne sera pas installé
        

        Pour libgl1-mesa-dri:i386.

        Ça avance, c'est déjà ça !

        • [^] # Re: sans titre

          Posté par . Évalué à 1 (+0/-0).

          Ah ? Je devrais donc ajouter les dépôts backport à mon sources.list ?

          Si c'est une installation Debian Stretch standard, tu ne devrais pas avoir un noyau 4.16 mais le 4.9 donc je présume qu'à un moment tu as utilisé les backports pour l'obtenir. J'imagine que tu as eu une bonne raison de ne pas rester avec le noyau 4.9 mais dans ce cas il vaut mieux réactiver ce dépot pour mettre à jour ta version de noyau parce que la 4.16 n'est plus prise en charge même dans backports.

          steam:i386 : Dépend: libudev1:i386 mais ne sera pas installé
          Dépend: libgl1-mesa-dri:i386 mais ne sera pas installé
          Dépend: libgl1-mesa-glx:i386 mais ne sera pas installé

          Ça indique que ça n'est pas en rapport avec backports vu que ces paquets sont présents dans les dépots stables.
          Il y a bien un truc avec ton installation et comme l'a dit NeoX ça a certainement rapport avec des paquets marqués onhold.

          • [^] # Re: sans titre

            Posté par . Évalué à 3 (+1/-0).

            Il y a bien un truc avec ton installation et comme l'a dit NeoX ça a certainement rapport avec des paquets marqués onhold.

            ou comme tu le suggerais, il a installé des paquets backports (noyau 4.16 par exemple), et fait un upgrade, puis supprimé le depot.

            il a alors des lib plus recentes que necessaires et les dependances sont alors cassées

            • [^] # Re: sans titre

              Posté par . Évalué à 1 (+0/-0).

              Effectivement il est peut-être en mesa 18 dans ses paquets AMD64 mais le apt-get -t stretch-backports sur le paquet libgl1-mesa-glx:i386 auraient dû résoudre la situation si ce n'était qu'une question de dépot manquant. Il y a quelque chose dans les dépendances de libgl1-mesa-dri:i386 qui bloque, ÀMHA vu les erreurs de sortie il y a blocage avec libdrm2 et zlib1g (et ce dernier n'est même pas un paquet backports).

              • [^] # Re: sans titre

                Posté par . Évalué à 1 (+0/-0).

                C'est possible que j'ai un jour utilisé les dépôts backports, mais je ne me souviens pas avoir volontairement changé la version de mon noyau…
                Après j'ai installé cette distrib en Avril 2018, et je débutais sur linux et encore plus sur Debian, donc j'ai pu faire un truc sans m'en rendre compte, même si ça m’étonnerais.

                il a alors des lib plus récentes que nécessaires et les dépendances sont alors cassées

                Dans ce cas, aptitude ne me proposerait-il pas de retrograder les paquets en question ? Car là il ne le fait pas.

                Au passage, j'avais déjà eu un problème de ce type avec Wine et j'avais fini par abandonner, mais comme steam comprend maintenant Proton, basé sur Wine, il pourrait y avoir un rapport ?

                • [^] # Re: sans titre

                  Posté par . Évalué à 1 (+0/-0). Dernière modification le 23/10/18 à 19:25.

                  Dans ce cas, aptitude ne me proposerait-il pas de retrograder les paquets en question ? Car là il ne le fait pas.

                  J'utilise aptitude en interface ncurses depuis des années et son système de résolution de conflits est parfois tordu, surtout quand ça implique backports. Il m'arrive régulièrement de devoir fouiller dans l'arbre de dépendance et d'installer manuellement un ou deux paquets pour arriver à mes fins parce qu'aucune des solutions trouvées par aptitude ne le fait.
                  En ligne de commande c'est encore pire vu que bien souvent aptitude ne propose que sa première suggestion qui, quand ça bloque, se résume à ne pas installer les nouveaux paquets ou à remplacer la moitié de ceux installés.

                  Pour ton problème, tente de voir si tu arrives à quelque chose avec le TUI d'aptitude en simulant les installations manuelles des paquets que j'ai cité à la fin de mon message précédent. Cherche jusqu'à ce qu'il n'y ait plus de message d'erreur. Tu peux revenir en arrière dans le menu Action (Ctrl+t) > Annuler les actions en attente (raccourci en touche l)

                  • [^] # Re: sans titre

                    Posté par . Évalué à 1 (+0/-0).

                    Désolé, j'ai vraiment du mal avec le TUI de aptitude, je préfère amplement la version en ligne de commande !
                    J'ai bien essayé de bidouiller quelques trucs, mais à chaque fois je retombe sur un conflit d'une lib qui ne peut être en 32 bits et en 64 bits à la fois…
                    Je dois avouer que je sèche complètement là !

                    • [^] # Re: sans titre

                      Posté par . Évalué à 1 (+0/-0).

                      Oui la TUI est spéciale mais pratique pour avoir une vue d'ensemble et le détail de chaque versions de paquets disponibles via les dépots.

                      Sinon avec l'option -t de apt-get, est-ce qu'installer la version de steam présente dans stable pose problème ? même question pour la version backports.

                      à chaque fois je retombe sur un conflit d'une lib qui ne peut être en 32 bits et en 64 bits à la fois

                      Quelles lib ? version stable ou backports ?

                      Le conflit entre les lib 32 et 64 peut arriver parce que aptitude cherche à installer la version stable de la 32 bits alors que tu as la version backports de la 64 ou vice versa.
                      Après ça peut arriver d'avoir des paquets mal fichus vu que backports est un court-circuit de testing/sid. Je me souviens d'avoir laché l'affaire sur le paquet backports de VLC.

                      On va regarder avec une dépendance qui ne dépend pas de backports :
                      Donne moi la sortie de la commande sudo apt-get install zlib1g:i386
                      puis si ça veut pas s'installer, même chose avec libc6:i386
                      puis libgcc1:i386
                      puis ces deux dernières dans la même commande
                      De ce que je vois il y a une boucle de dépendance entre ces deux libs, ça pourrait éventuellement mettre le souk dans la résolution de apt et aptitude. Vu que ce sont des libs indispensables à beaucoup de programmes ça pourrait tout résoudre d'un coup.
                      Si elles ne veulent pas s'installer, il va falloir forcer leur installation.

                      • [^] # Re: sans titre

                        Posté par . Évalué à 1 (+0/-0).

                        Rien avec apt-get -t stretch-backports…
                        Pour le conflit, j'ai essayé de remonter aux sources, en essayant d'installer la première lib qui casse au fur et à mesure : libgl1-mesa-dri:i386 puis libdrm-amdgpu1:i386 puis libdrm2:i386 et c'est la que ça coince.

                        user@debian:~$ sudo aptitude show libdrm2
                        Paquet : libdrm2                                        
                        Version : 2.4.95-1~bpo9+1
                        État: installé
                        Automatiquement installé: non
                        Multiarchitecture : même
                        Priorité : optionnel
                        Section : libs
                        Responsable : Debian X Strike Force <debian-x@lists.debian.org>
                        Architecture : amd64
                        Taille décompressée : 114 k
                        Dépend: libdrm-common (>= 2.4.95-1~bpo9+1), libc6 (>= 2.17)
                        Casse: libdrm2:i386 (!= 2.4.95-1~bpo9+1)
                        Remplace: libdrm2:i386 (< 2.4.95-1~bpo9+1)
                        

                        Les versions 32 et 64 bits ne peuvent pas coexister, et je doute que ça soit la seule lib qui pose problème ainsi.

                        Les trois libs en questions étaient déjà installées, donc pas d'erreurs à ce niveau la.

                        • [^] # Re: sans titre

                          Posté par . Évalué à 1 (+0/-0).

                          Casse: libdrm2:i386 (!= 2.4.95-1~bpo9+1)

                          OK, du coup le truc qui bloque c'est que en 64bits tes libs mesa, drm et wayland sont toujours en version stable, il faut les upgrader en backports pour que ça passe.
                          Je viens de tester chez moi et ce n'est pas trivial, aptitude a bien du mal parce que effectivement c'est pas la seule lib à casser, mais à force d'insister manuellement ça fonctionne.

                          Paquets à mettre à jour :
                          libdrm-amdgpu1 libdrm-nouveau2 libdrm-intel1 libdrm-radeon1 libdrm2 libegl1-mesa libgbm1 libgl1-mesa-dri libwayland-client0 libwayland-server0

                          • [^] # Re: sans titre

                            Posté par . Évalué à 1 (+0/-0).

                            Bonjour et désolé du délai.
                            Malgré un

                            sudo apt -t stretch-backports install libdrm-amdgpu1 libdrm-nouveau2 libdrm-intel1 libdrm-radeon1 libdrm2 libegl1-mesa libgbm1 libgl1-mesa-dri libwayland-client0 libwayland-server
                            

                            Rien n'a été mis à jour et Steam bloque toujours…

                            • [^] # Re: sans titre

                              Posté par . Évalué à 1 (+0/-0).

                              c'est apt-get , pas apt ;)
                              Pas de problème pour le délai, par contre ici tu ne me donnes pas plus d'infos pour continuer à t'aider donc tout ce que je peux dire c'est qu'il faut que tu persistes à chercher pourquoi libdrm2 64bits en version backports ne veut pas s'installer sur ta Debian.

                              • [^] # Re: sans titre

                                Posté par . Évalué à 1 (+0/-0).

                                Même avec apt-get, il me dit que les paquets sont à jour.
                                libdrm2 64bits était bien installée, c'était la version 32 bits qui coincait, mais pour une raison inconnue, après une mise à jour, un simple sudo apt install -t stretch-backports libdrm2:i386 a eu raison de lui.
                                Malgré ca, le paquet Steam bloque toujours au même endroit, et si je remonte aux paquets sources qui posent problème, il y en a beaucoup.
                                Voici un schéma de la situation:
                                Schéma

                                J'ai pas tout essayé en 64 bits mais a chaque essai, la lib était bien installée en 64 bits.
                                Le soucis vient peut être d'un problème plus global du support multi-arch sur mon ordi !

                                • [^] # Re: sans titre

                                  Posté par . Évalué à 1 (+0/-0).

                                  libdrm2 64bits était bien installée, c'était la version 32 bits qui coincait, mais pour une raison inconnue, après une mise à jour, un simple sudo apt install -t stretch-backports libdrm2:i386 a eu raison de lui.

                                  "Après une mise à jour" ça veut dire quoi ? apt-get upgrade ou update ? Et ça a mis à jour quels paquets ?

                                  J'ai pas tout essayé en 64 bits mais a chaque essai, la lib était bien installée en 64 bits.

                                  En version backports ? et quelle version de Steam : stable, backports ou celle du dépot tiers de Valve ? parce que le schéma que tu montres c'est typiquement ce qu'il se passe avec une dépendance backports qui veut pas se mettre à jour.
                                  Un paquet comme libdrm-amdgpu1:i386 ne dépend que de libdrm2:i386 donc maintenant tu devrais pouvoir l'installer en backports si tu as bien le paquet amdgpu1 64bits qui est installé en backports.
                                  Le support du multi-arch n'a pas de soucis particuliers, c'est plutôt backports qui pose généralement des problèmes de résolution de conflits même sans multi-arch (et pour preuve : rien qu'installer les paquets backports 64bits rend fou le gestionnaire de paquets).

                                  Continue de creuser les dépendances et conflits, je suis certain que tu retomberas à peu près sur la liste que j'avais eu avec aptitude (et franchement c'est bien plus simple à gérer avec le TUI ou un bon GUI). Après je n'ai pas KDE donc ça pourrait aussi ajouter des conflits supplémentaires.

                                  • [^] # Re: sans titre

                                    Posté par . Évalué à 1 (+0/-0).

                                    Oui, après un update & upgrade.
                                    Je ne me souviens plus des paquets mis à jour mais après ca, l'installation de libdrm2:i386 via backports ca bien fonctionné.

                                    J'ai compris comment fonctionnait le TUI de aptitude, ce qui simplifie grandement les choses !
                                    Voici un screenshot pour libgl1-mesa-dri:i386:
                                    TUI Aptitude

                                    Certaines libs sont disponibles en backports et d'autres non, ca pourrait venir d'ici ?

                                    C'est assez similaire pour libgl1-mesa-glx:i386, sauf que une des lib est dispo en backports et pas en stable.

                                    TUI Aptitude2

                                    Je précise que ces images sont prises sur la version backports de ces paquets.
                                    J'ai beau tenter et chercher partout, backports ou pas, à chaque fois un conflit 32/64 bits…

                                    • [^] # Re: sans titre

                                      Posté par . Évalué à 1 (+0/-0).

                                      Certaines libs sont disponibles en backports et d'autres non, ca pourrait venir d'ici ?

                                      En partie oui. backports a une priorité basse par rapport aux dépôts stable donc la résolution ne fonctionne pas bien quand il y a plusieurs paquets backports à installer ou mettre à jour automatiquement. Avec un paquet simple en dépendance, le gestionnaire de paquets trouve facilement et propose l'installation des nouveaux paquets backports. Ici tu as plusieurs paquets avec de multiples dépendances profondes à résoudre, c'est trop compliqué pour le gestionnaire.

                                      Remarque bien que là sur tes screenshots ce ne sont pas les dépendances elles-mêmes qui bloquent (si tu regardes le numéro de version des dépendances disponibles, il est bien supérieur ou égal à celui exigé par le paquet) mais ce sont des paquets encore en-dessous. En descendant plus profond tu vas trouver les coupables.

                                      J'ai beau tenter et chercher partout, backports ou pas, à chaque fois un conflit 32/64 bits…

                                      Oui tu arrives à des paquets avec des conflits non pas dans la partie Dépend mais dans la partie Casse, probablement en 64bits et restés en stable. C'est une partie de la difficulté de l'opération qui contribue à mettre en défaut la résolution automatique. Les lib graphiques en multiarch doivent être de même version. C'est pour ça que j'insiste sur les paquets 64bits. :)

                                      Tente de simuler l'installation d'un de ces paquets avec aptitude, regarde à chaque manipulation ce qu'il propose comme solutions de résolution (parfois il faut faire suivant jusque sa quatrième ou cinquième solution pour avoir quelque chose qui convient), regarde ce qu'il indique comme conflits et creuse jusqu'à ce qu'un paquet propose la bonne solution de résolution. C'est comme ça que j'ai fait pour libdrm2:i386
                                      Il y a de fortes chances qu'il faille faire ça à plusieurs endroits mais tu vas aussi avoir des sous-dépendances communes qui débloquent plusieurs paquets supérieurs. Et comme tu l'as supposé, ça va fortement aider à résoudre ton problème similaire avec Wine.

                                      C'est un travail de détective. Avec l'habitude de l'outil, tu finiras par régler ce genre de problème en quelques minutes. Surtout qu'après avoir résolu des grosses lib graphiques, toi et le gestionnaire auront beaucoup moins de conflits à résoudre, jusqu'à la prochaine dist-upgrade.

                                      • [^] # Re: sans titre

                                        Posté par . Évalué à 1 (+1/-0).

                                        Super, je vais continuer de chercher avec aptitude, je vous tiens au courant !

                • [^] # Re: sans titre

                  Posté par . Évalué à 1 (+0/-0).

                  aptitude donne les explications pour les conflits sur chaque paquet dans le panneau du bas: "e" pour examine, et se balader dans la liste des paquets. "." (point) permet d'explorer les différentes hypothèses de résolution.

                  N'aurais tu pas utilisé le pinning (voir /etc/apt/preferences.d/*)?

                  On peut ajouter la provenance d'un paquet dans l'affichage de aptitude (stable, oldstable, etc…) via
                  options -> préférences, dans "Format d'affichage pour la vue des paquets".
                  Par exemple "%c%a%M%S %p %Z %v %V %t %i %m"

                  • [^] # Re: sans titre

                    Posté par . Évalué à 1 (+0/-0).

                    Je n'ai pas utilisé le pinning non, le dossier preferences.d n'existe même pas.
                    Sinon je n'ai pas trouvé grand chose d’intéressant via le TUI d'aptitude.

Envoyer un commentaire

Suivre le flux des commentaires

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