Sujet : utilisation d'apt ou synaptic avec apt-listbugs sous debian sid |
THRAK |
Oui et non :D En fait, c'est un peu plus complexe que "le paquet qui dépend de celui bugué sera ou ne sera pas installé", car les dépendances correspondent à un certains nombre de conditions (inclues dans un fichier d'en-tête) nécessaires pour que le paquet puisse fonctionner. Ceci permet bien sûr de spécifier qu'un paquet à besoin de tel autre pour fonctionner, mais va plus loin en permettant de définir que la version dudit paquet nécessite une version inférieure, supérieure ou égale à telle version du paquet dont elle dépend, que celle-ci entre en conflit avec tel paquet ou telle version d'un autre paquet, ou encore que tel paquet est recommandé, suggéré, etc.
Dans cette optique, on peut imaginer le cas où tu décides de ne pas mettre à jour un paquet parce qu'il est bugué, mais où tu verras par exemple qu'une dépendance est tout de même mise à jour ; c'est possible si l'on considère que la nouvelle version de cette dépendance n'empêche pas ton paquet bugué de fonctionner et est simultanément requise en raison de la mise à jour d'autres paquets qui en dépendent également. A contrario, l'effet inverse peut aussi se produire, à savoir que ton paquet bugué, pour pouvoir continuer à fonctionner, va indirectement empêcher la mise à jour d'un ou plusieurs autres paquets en raison d'un conflit de version sur la dépendance qu'ils ont en commun ; ouf... :pt1cable: :p La gestion des dépendances est loin d'être évidente donc, et reste difficilement représentable dans certains cas de figure, c'est justement pour cela qu'on a créé les gestionnaires de paquets dits "avancés" (avec gestion des dépendances) comme apt-get ou plus évolué, aptitude. Cela signifie qu'il est conseillé au niveau des dépendances de laisser le gestionnaire de paquet prendre les décisions (bonnes la majeure partie du temps) ; celles-ci seront traitées automatiquement en fonctions des critères que j'ai indiqué ci-dessus.
Sinon apt-listbugs ne permet pas de choisir de conserver tel ou tel paquet bugué et de mettre à jour tel ou tel autre paquet bugué (quand plusieurs paquets différents contiennent des bugs lors d'une même mise à jour -ce qui est souvent le cas) ; à ce moment-là la meilleure possibilité est d'interrompre la mise à jour, de bloquer manuellement via son gestionnaire favori les paquets qu'on ne souhaite pas mettre à jour et de relancer la mise à jour. C'est un peu laborieux, mais c'est aussi pour cela qu'il n'est pas conseillé de faire des maj entièrement automatisées dans Sid :D |
THRAK |
Oui et non :D En fait, c'est un peu plus complexe que "le paquet qui dépend de celui bugué sera ou ne sera pas installé", car les dépendances correspondent à un certains nombre de conditions (inclues dans un fichier d'en-tête) nécessaires pour que le paquet puisse fonctionner. Ceci permet bien sûr de spécifier qu'un paquet à besoin de tel autre pour fonctionner, mais va plus loin en permettant de définir que la version dudit paquet nécessite une version inférieure, supérieure ou égale à telle version du paquet dont elle dépend, que celle-ci entre en conflit avec tel paquet ou telle version d'un autre paquet, ou encore que tel paquet est recommandé, suggéré, etc.
Dans cette optique, on peut imaginer le cas où tu décides de ne pas mettre à jour un paquet parce qu'il est bugué, mais où tu verras par exemple qu'une dépendance est tout de même mise à jour ; c'est possible si l'on considère que la nouvelle version de cette dépendance n'empêche pas ton paquet bugué de fonctionner et est simultanément requise en raison de la mise à jour d'autres paquets qui en dépendent également. A contrario, l'effet inverse peut aussi se produire, à savoir que ton paquet bugué, pour pouvoir continuer à fonctionner, va indirectement empêcher la mise à jour d'un ou plusieurs autres paquets en raison d'un conflit de version sur la dépendance qu'ils ont en commun ; ouf... :pt1cable: :p La gestion des dépendances est loin d'être évidente donc, et reste difficilement représentable dans certains cas de figure, c'est justement pour cela qu'on a créé les gestionnaires de paquets dits "avancés" (avec gestion des dépendances) comme apt-get ou plus évolué, aptitude. Cela signifie qu'il est conseillé au niveau des dépendances de laisser le gestionnaire de paquet prendre les décisions (bonnes la majeure partie du temps) ; celles-ci seront traitées automatiquement en fonctions des critères que j'ai indiqué ci-dessus.
Sinon apt-listbugs ne permet pas de choisir de conserver tel ou tel paquet bugué et de mettre à jour tel ou tel autre paquet bugué (quand plusieurs paquets différents contiennent des bugs lors d'une même mise à jour -ce qui est souvent le cas) ; à ce moment-là la meilleure possibilité est d'interrompre la mise à jour, de bloquer manuellement via son gestionnaire favori les paquets qu'on ne souhaite pas mettre à jour et de relancer la mise à jour. C'est un peu laborieux, mais c'est aussi pour cela qu'il n'est pas conseillé de faire des maj entièrement automatisées dans Sid :D |
thierry_b |
Bonjour,
Je voudrais vous poser une petite question sur l'utilisation d'apt-listbugs, avec apt ou synaptic.
Je préfère utiliser apt-listbugs, vu que je suis retourné en sid, et que je veux eliminer les désavantages de la sid lol.
apt-listbugs marche bien, mais je voulais savoir qque chose.
Par exemple, il m'a detecté un bug grave sur k3blibs, donc moi j'ai choisi "n", pour interrompre l'install.
Y'a une option qui dit de bloquer ce paquet pour ne as l'installer.
Mais moi, j'aimerais savoir s'il y a moyen de lui dire que le blocage est temporaire et juste du à cette execution (comme ca si à une prochaine utilisation d'apt, apt-listbugs ne detecte plus ce bug, il pourra installer ce paquet, auquel cas on serait obligé de debloquer manuellement le paquet, ce qui serait assez lourd...lol), et aussi de lui dire de bloquer les paquets qui dependant du paquet bugué.
Car, comme il m'a affiché, ce pb avec k3blibs, ca aurait ete assez bete, qu'il bloque k3blibs, et qu'il mette à jour le paquet k3b lol...
Je vous remercie :-)
A+ |