"testing" comment gérer "Laisser les dépendances suivantes"

Bonjour,
Je suis contraint (je n’ai vraiment pas le choix) d’utiliser une “testing”, donc j’aimerais savoir comment m’y prendre pour maintenir ma “testing” à jour. Ce que je recherche c’est la méthode, pas une réponse sur un cas précis, parce que je ne veux pas vous déranger à chaque fois.

J’ai configuré mon “source.list”, “apt.conf” et “preferences” pour utiliser “testing”. J’ai installé “apt-listbugs”.

Quand je tente un “aptitude update; aptitude dist-ugrade”, j’ai ce qui suit :

[quote]aptitude dist-upgrade
Lecture des listes de paquets…
Construction de l’arbre des dépendances…
Lecture des informations d’état…
Lecture de l’information d’état étendu…
Initialisation de l’état des paquets…
Lecture des descriptions de tâches…
Les NOUVEAUX paquets suivants vont être installés :
libcogl-pango20{a} libcogl-path20{a} libcogl20{a} libxatracker2{a}
Les paquets suivants seront mis à jour :
cups cups-bsd cups-client cups-common cups-core-drivers cups-daemon
cups-ppdc cups-server-common db5.1-util{b} gir1.2-clutter-1.0
gir1.2-cogl-1.0 gir1.2-coglpango-1.0 gir1.2-packagekitglib-1.0
gnome-sushi gstreamer1.0-clutter libcheese-gtk23 libclutter-1.0-0{b}
libclutter-gst-2.0-0 libclutter-gtk-1.0-0 libcups2 libcupscgi1
libcupsimage2 libcupsmime1 libcupsppdc1 libegl1-mesa libegl1-mesa-drivers
libgbm1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libgles2-mesa
libgtk2-perl libopenvg1-mesa libpackagekit-glib2-16 libpam-systemd
libruby2.0 libsystemd-daemon0 libsystemd-journal0 libsystemd-login0
libwayland-egl1-mesa mobile-broadband-provider-info openssh-client
openssh-server openssh-sftp-server packagekit packagekit-backend-aptcc
packagekit-tools python3-packagekit ruby2.0 synaptic systemd
xserver-common xserver-xorg-core xserver-xorg-video-vmware
54 paquets mis à jour, 4 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de télécharger 0 o/28,2 Mo d’archives. Après dépaquetage, 4 706 ko seront utilisés.
Les paquets suivants ont des dépendances non satisfaites :
db5.1-util : Casse: libdb5.1 (< 5.1.29-8~) mais 5.1.29-6 est installé.
libclutter-1.0-0 : Casse: libcogl12 mais 1.14.0-3 est installé.
Les actions suivantes permettront de résoudre ces dépendances :

  Supprimer les paquets suivants :                                          
  1.  gir1.2-clutter-1.0                                                      
    
  2.  gir1.2-clutter-gst-2.0                                                  
    
  3.  gir1.2-gtkclutter-1.0                                                   
    
  4.  gnome-control-center                                                    
    
  5.  gnome-sushi                                                             
    
  6.  gstreamer1.0-clutter                                                    
    
  7.  libcheese-gtk23                                                         
    

8) libcheese7
9) libclutter-1.0-0
10) libclutter-gst-2.0-0
11) libclutter-gtk-1.0-0
12) libdb5.1

  Laisser les dépendances suivantes non satisfaites :                       
  1. gnome-bluetooth recommande gnome-control-center                         
    
  2. gnome-control-center-data recommande gnome-control-center (>= 1:3.8.3-4)
    
  3. gnome-online-accounts recommande gnome-control-center (>= 3.6.1)        
    
  4. mousetweaks recommande gnome-control-center                             
    
  5. nautilus recommande gnome-sushi                                         
    

Accepter cette solution ? [Y/n/q/?][/quote]

S’il vous plaît, quelqu’un peut-il me guider, m’expliquer comment gérer la situation “Laisser les dépendances suivantes non satisfaites” ?

Comment faut-il faire pour maintenir une testing à jour ?

Merci pour l’aide que vous pourrez m’apporter.

Salut,

Dans l’ordre de mes préférences;

1 - Rester en stable avec un fichier “preferences” autorisant seulement les paquets indispensables à passer en testing

2 - Utiliser aptitude safe-upgrade plutôt que dist-upgrade

3 - Apprendre à utiliser aptitude pour savoir dire non à certaines solutions et à naviguer dans les solutions proposées.

Merci pour ta réponse Ggoodluck47

Très bonne idée, mais comme le le disais, je n’ai vraiment pas le choix, les conditions m’imposent “testing”… Et c’est une occasion d’en apprendre un peu plus sur l’administration d’une Debian :slightly_smiling:

J’ai fait en premier “aptitude safe-upgrade”, puis seulement après un “aptitude dist-upgrade” : c’est ce que je fais sur ma “stable”. Sous “testing”, avec “aptitude safe-upgrade” j’avais “systemd” que “apt-listbugs” signalais dans un tel état qu’il stoppait (sortie sur erreur) d’installer quoi que ce soit. Je l’ai donc éliminer de la mise à jour de “systemd” et le “safe-upgrade” est passé sans problème.

Ne faut-il pas faire de “dist-upgrade” sous testing ?

[quote=“ggoodluck47”]
3 - Apprendre à utiliser aptitude pour savoir dire non à certaines solutions et à naviguer dans les solutions proposées.[/quote]
J’ai navigué dans toutes les solutions proposée par aptitude, mais je me retrouve toujours avec la propostion “Laisser les dépendances suivantes non résolues”.

Je voudrais donc apprendre à gérer une telle situation sous “testing”, s’il cela doit être fait, pour maintenir la distribution à jour.

Salut,

Que se soit pour administrer une stable ou une testing on peut utiliser apt-get ou aptitude, mais tu mélanges un peu les synthaxes des deux.

Je crois que ce sera plus clair avec :

debian.org/doc/manuals/debia … ommandline

(Paragraphe 2.2.2 en particulier)

Bonjour,

Effectivement, petite confusion (mais qui revient au même heuresement) : “aptitude full-updrage” ou “apt-get dist-upgrade”.

Merci beaucoup pour le lien, je vais regarder cela.

Je suis toujours preneur de tout bon conseil pour maintenir une testing à jour :slightly_smiling:

J’utilise aptitude dist-upgrade par habitude…

Par curiosité, qu’à tu fais à ton fichier apt.conf? En fait que contiennent tes fichier sources.list et preferences.

Tu peux essayer apt-get. Parfois, il passe là où aptitude s’enlise.

Mes fichiers :
/etc/apt/apt.conf[quote]APT::Default-Release “testing”;
// consider Recommends, Suggests as important dependencies that should
// be installed by default
APT::Install-Recommends “true”;[/quote]
/etc/apt/preferences[quote]Package: *
Pin: release o=Debian, a=stable
Pin-Priority: 499
Package: *
Pin: release o=Debian, a=unstable
Pin-Priority: 490[/quote]

Précise ta “contrainte” et je t’expliquerai comment faire la même chose avec une stable :wink:

Voici la situation, nous avons un parc en ScientificLinux (RedHat version CERN) et dans ce contexte une expérience minimale de Debian, c’est surtout parce qu’à titre personnel je tourne sous Debian que je m’en sort. Maintenant, il y des utilisateurs qui ont besoin des toutes dernières versions des paquets Debian pour faire du développement, souvent en liaisosn avec du développement matériel. Donc l’utilisateur a installé une Debian, mais c’est un poste qui n’est pas peut-être pas géré comme il convient, de là notre volonté de répondre à la demande des utilisateurs, mais en assurant une bonne gestion des postes.

D’où ma question : comment maintenire une Debian “testing” à jour ?

S’il y a d’autres façons de faire, je suis désireux d’apprendre tout ce que je pourrai !

[quote=“peekpoke”]Voici la situation, nous avons un parc en ScientificLinux (RedHat version CERN) et dans ce contexte une expérience minimale de Debian, c’est surtout parce qu’à titre personnel je tourne sous Debian que je m’en sort. Maintenant, il y des utilisateurs qui ont besoin des toutes dernières versions des paquets Debian pour faire du développement, souvent en liaisosn avec du développement matériel. Donc l’utilisateur a installé une Debian, mais c’est un poste qui n’est pas peut-être pas géré comme il convient, de là notre volonté de répondre à la demande des utilisateurs, mais en assurant une bonne gestion des postes.

D’où ma question : comment maintenire une Debian “testing” à jour ?

S’il y a d’autres façons de faire, je suis désireux d’apprendre tout ce que je pourrai ![/quote]

J’en convient qu’avoir les dernières version peut-être utile voir indispensable dans certains cas mais Tsting n’est clairement pas la version la plus simple à maintenir de TOUT temps.

Regarde plutôt les articles du wiki sur le pinning (étiquettage) et le sources.list (fichiers de sources) afin de te concocter une Debian en version Unstable et à toi de freezer lorsqu’un bug sera vraiment incapacitant.
Tu aura le mérite d’être à jour et de t’assurer qu’en cas de réel problème la mise à jour salvatrice arrivera bien plus tôt qu’en version Testing.

Comme dit plus haut j’utilise presque exclusivement aptitude mais apt-get parfois passe (plus en force :005 ) le reste ces affaires de goûts.

Par curiosité et sachant qu’il y a quelque personnes travaillant dans le milieu scientifique quels sont les logiciels en particulier méritant un traitement si particulier ?

Ce genre de situation est dû à une incompatibilité entre les versions de certains paquets et de leurs dépendances. Si aucune des solutions proposées par aptitude ne te convient, le plus sage est d’attendre et de réessayer plus tard. Ça finit généralement par rentrer dans l’ordre.

Pour ce qui est du message qui d’aptitude qui te pose problème, « Laisser les dépendances suivantes non satisfaites : », tu peux en effet les laisser non satisfaites sans souci.
Il s’agit de paquets “recommandés”, c’est-à-dire étendant les fonctionnalités d’un autre paquet mais sans être essentiels à son utilisation (sur mon système ces paquets ne sont pas installés par défaut et je ne les ajoute qu’au cas par cas).

Si le besoin de versions récentes est lié à du développement, comme Clochette je te conseille de passer franchement en Sid (avec le paquet apt-listbugs pour éviter au maximum qu’un bug ne débarque par surprise).

Si le nombre de ces paquets est faible il doit être possible, au choix :
_de rester en stable et d’utiliser l’étiquetage via le fichier preferences pour installer les versions testing/sid de ces paquets
_de rester en stable et de compiler les dernières versions des paquets sur les bibliothèques de Wheezy (depuis l’upstream ou depuis les versions testing/sid selon le besoin de fraîcheur)

Je conseille dans ce cas de préférer la compilation qui nécessitera la mise-à-jour de moins de paquets que l’étiquetage. Elle demande par contre un peu plus de boulot de maintenance que l’étiquetage, en particulier pour les paquets recevant des mises-à-jour fréquentes.

[quote=“Green”]Salut,

Que se soit pour administrer une stable ou une testing on peut utiliser apt-get ou aptitude, mais tu mélanges un peu les synthaxes des deux.

Je crois que ce sera plus clair avec :

debian.org/doc/manuals/debia … ommandline

(Paragraphe 2.2.2 en particulier)[/quote]

Merci beaucoup pour ce lien, j’ai lu le chapitre 2 avec beaucoup d’intérêt. Je regrette de ne découvrir que maintenant toutes ces informations.

Il serait bien que cela soit plus connu. Un lien dans le Wiki ?

[quote=“vv222”]Pour ce qui est du message qui d’aptitude qui te pose problème, « Laisser les dépendances suivantes non satisfaites : », tu peux en effet les laisser non satisfaites sans souci.
Il s’agit de paquets “recommandés”, c’est-à-dire étendant les fonctionnalités d’un autre paquet mais sans être essentiels à son utilisation (sur mon système ces paquets ne sont pas installés par défaut et je ne les ajoute qu’au cas par cas).

Si le besoin de versions récentes est lié à du développement, comme Clochette je te conseille de passer franchement en Sid (avec le paquet apt-listbugs pour éviter au maximum qu’un bug ne débarque par surprise).

Si le nombre de ces paquets est faible il doit être possible, au choix :
_de rester en stable et d’utiliser l’étiquetage via le fichier preferences pour installer les versions testing/sid de ces paquets
_de rester en stable et de compiler les dernières versions des paquets sur les bibliothèques de Wheezy (depuis l’upstream ou depuis les versions testing/sid selon le besoin de fraîcheur)

Je conseille dans ce cas de préférer la compilation qui nécessitera la mise-à-jour de moins de paquets que l’étiquetage. Elle demande par contre un peu plus de boulot de maintenance que l’étiquetage, en particulier pour les paquets recevant des mises-à-jour fréquentes.[/quote]

Merci beaucoup, je vais essayer de mettre en oeuvre ces conseils.