Prenons le sources.list du truc & astuces. Un
$ apt-cache policy
donne
On constate que toutes les préférences sont à 500 sauf pour les paquets installés. Rappelons que ces préférences sont interprétés comme suit:
Imaginons que on veuille faire une etch comportant éventuellement quelques nouveautés lenny ou sid. On écrirait dans le fichier preferences avec le deuxième fichier preferences du fil Trucs et Astuces (il vaut mieux utiliser le premier, cf explications sur le fil, cette version se prête mieux aux explications à cause des priorités différentes données aux dépots)
Les différents «tags» o=, c= sont issues directement de la sortie d’«apt-cache policy», ainsi
[quote] 500 boisson.homeip.net etch/inspiron Packages
release o=Boisson,a=etch,l=Debian,c=inspiron
origin boisson.homeip.net
[/quote] donne bien o=Boisson et c=inspiron pour ce dépot.
On s’aperçoit que ici, le dépot apt-build (local) est prioritaire, puis que mes paquets persos seront installés avec comme priorités
divers > exp > inspiron > etch.
La distribution etch étant complète, à priori un paquet ne sera pas jamais pris dans les dépots lenny ou sid. Cela peut être ennuyeux car cela peut conduire à une impasse si par exemple ici le dépot boisson.homeip.net est incomplet. Exemple:
Là tout va bien, mais supposons que le paquet libclamav3 n’existe pas sur le dépot Boisson:
[quote]bling:/# apt-cache policy libclamav3
libclamav3:
Installé : (aucun)
Candidat : 0.92.1~dfsg-1volatile2
Table de version :
0.92.1~dfsg2-1.1 0
95 ftp.fr.debian.org sid/main Packages
0.92.1~dfsg2-0.1 0
97 ftp.fr.debian.org lenny/main Packages
0.92.1~dfsg-1volatile2 0
989 ftp.ens-cachan.fr etch/volatile/main Packages
bling:/# apt-get install clamav
Lecture des listes de paquets… Fait
Construction de l’arbre des dépendances… 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.
Puisque vous n’avez demandé qu’une seule opération, le paquet n’est
probablement pas installable et vous devriez envoyer un rapport de bogue.
L’information suivante devrait vous aider à résoudre la situation :
Les paquets suivants contiennent des dépendances non satisfaites :
clamav: Dépend: libclamav3 (>= backport-0.92-1) mais ne sera pas installé
E: Paquets défectueux
bling:/#
[/quote]On est déçu, on peut retenir que ce dépot est tenu par un être négligent et irresponsable. Il existe des solutions fiables dans le dépot backport ou lenny mais ne correspondant pas à la version de clamav devant être installé. Une solution consiste pour gérer ça à imposer l’origine du paquet clamav:
On est déçu . Evidemment, il y a le souci de la libc6, on peut soit se rabattre sur une autre origine (le volatile), soit essayer d’utiliser aptitude qui est plus futé qu’apt-get dans ce genre de cas:
À noter que dans l’exemple ci dessus, clamav-base viendra du dépot boisson.homeip.net. Le pinning permet une bonne gestion des paquets mais cela doit être fait avec soin.
aptitude permet de se sortir de situations apparemment bloquées: Ainsi, si on reprend la situation avec clamav venant de lenny:
aptitude trouve des solutions mais on peut noter ici parmi les différentes propositions une proposition d’installation de locales venant d’«experimental» (c’est une mauvaise idée sur une etch ).
L’épinglage («pinning») de paquet est surtout pratique pour forcer un backport pour un paquet venant d’un site précis proposant les paquets (en nombre limité) nécessaire à ce backport. Souvent l’installation devra se faire par aptitude pluôt que apt-get car des compromis pourront être nécessaire (cf ci-dessus).
Un mauvais épinglage entraine le message paquets cassés d’apt-get qui signifie juste que vous vous êtes trompé dans l’écriture de votre sources.list. De même pour le message paquet manquant.
Rappel: Il n’y a aucun souci à utiliser apt-get et aptitude en même temps.
Ce topic me fait rappeler que matt m’avait demandé si je pouvais écrire un tuto sur l’exploitation du fichier Release d’un dépot. C’est à dire comment indiquer les préférences avec ce fichier : boisson.homeip.net/debian/dists/etch/Release. On pourrait le faire dans ce topic ?
Ça n’est pas très simple,
Un fichier dists/etch/borp/binary-amd64/Release
Archive: Archive
Component: Component
Origin: Origine
Label: Label
Architecture: amd64
donne
[quote] 500 boisson.homeip.net etch/borp Packages
release o=Boisson,a=etch,l=Debian,c=borp
[/quote]
simplement parce qu’il y a un autre fichier dists/etch/Release contenant
[quote]Origin: Boisson
Archive: etch
Label: Debian
Suite: etch
Codename: etch
Architectures: amd64 i386
Components: divers exp inspiron jeu lineo
Description: Paquet divers F. Boisson
[/quote]
les champs peuvent se surcharger…
Toutes tes priorités sont entre 1000 et 990 et ajoutées en y retranchant 1 à chaque fois (999, 998 997…) donc d’après ton rappel :
[quote]990 < P <=1000
La version sera installée, même si elle n’appartient pas à la distribution par défaut ; mais elle ne sera pas installée si la version installée est plus récente.[/quote]
Maintenant si j’ai plus de 10 dépots à rajouter avec priorité entre 1000 et 990 … je peux avoir plusieur fois la meme valeur ? si oui pourquoi ne pas mettre 999 ou autre partout ?
Je préfère personnellement ordonner explicitement avec des prios différentes plutot que de tabler sur une propriété d’ordonnancement comme l’ordre dans le fichier qui n’existe qu’en raison de la manière dont c’est implémenté, mais qui n’est pas une propriété voulue: on ne sait jamais, le développeur peut changer de logique d’implémentation.
Sinon, … je ne sais plus si c’est toi qui m’avait suggéré de baisser les prios en dessous de 990 pour éviter de casser le fonctionnement du -t qui met une prio à 990 sur la release choisie, mais aprés expérimentation, il faut effectivement baisser les prios et il va falloir que j’ajuste mon tuto pour intègrer ça.
En théorie les paquets ayant le même numéro de version sont strictement les mêmes (cf Unstable/Testing), si ce n’est pas le cas c’est un problème de maintenance des dépôts/paquets et c’est surtout l’apanage des dépôts tiers. Il faut aussi garder à l’esprit que d’ « ordonner explicitement avec des prios différentes » chaque dépôts peut avoir des effets pervers (cf dépôts main/security pour Testing ).
Je préfère pour ma part partir du principe qu’une installation standard (donc avec les dépôts standards de même priorité) ne pose aucun problème et si changer l’ordonnancement des dépôts standards d’une même branche est parfois envisageable ce n’est jamais un acte anodin et ne devrait généralement se faire que de manière ponctuelle.
Pour les dépôts tiers le choix de leurs priorités devrait se faire au cas par cas en fonction des paquets qu’ils proposent et du comportement que l’on désir.
je pensais qu’elle faisait la même chose.
petite particularité la deuxième permet le downgrade.
Je précise que mes priorités sont supérieur pour sid 990, testing 980
[quote]
500 < P <=990
La version sera installée, sauf s’il existe une version appartenant à la distribution par défaut ou si la version installée est plus récente.
100 < P <=500
La version sera installée, sauf s’il existe une version appartenant à une autre distribution ou si la version installée est plus récente.[/quote]
donc de 100 @ 500 = La version sera installée, sauf s’il existe une version appartenant à une autre distribution ou si la version installée est plus récente
& de 500 @ 990 = La version sera installée, sauf s’il existe une version appartenant à la distribution par défaut ou si la version installée est plus récente.
maintenant lorsque l’on choisi le chiffre 500 lequel prend t il en compte ??? le 500 de 100 @ 500 ou le 500 de 500 @ 900 …
ps : non non ce n’est pas du trolling …c’est pour reellement comprendre
En outre il faut faire attention à l’interprétation de ce tableau des priorités qui implique que l’on a bien spécifié une distribution par défaut dans /etc/apt/apt.conf ou équivalent (ex: Default-Release “stable”;). L’interprétation que fera Apt des priorités peut être légèrement différente si l’on a pas spécifié une distribution par défaut.
apparement on peut mettre le nom de la branche depuis peu, j’viens de remarquer ça,
donc ça doit être récent.
par exemple pour une ligne ds le sources.list concernant lenny.
apt-cache policy donne une nouvelle option (n=lenny)
[quote]900 ftp.fr.debian.org lenny/main Packages
release v=5.0.2,o=Debian,a=stable,n=lenny,l=Debian,c=main[/quote]
donc on peut rajouter ds le fichier preferences ce style d’imterpretation.
j’ai une suggestion ,il serai pratique de pouvoir rétrograder dans une version antérieur. car les mise a jours (surtout en ce moment…) peuve poser des problème assez génan alors que les version antérieur marchai très bien.
le souci ce pose alors a la chaîne des dépendances car on veux garder que certaine version.
sa doit être possible mai je ne voit pas comment ?
[quote=“panthere”]j’ai une suggestion ,il serai pratique de pouvoir rétrograder dans une version antérieur. car les mise a jours (surtout en ce moment…) peuve poser des problème assez génan alors que les version antérieur marchai très bien.
le souci ce pose alors a la chaîne des dépendances car on veux garder que certaine version.
sa doit être possible mai je ne voit pas comment ?[/quote]
Si t’as les depots necessaire dans ton source.list :
Par exemple l’autre jour j’ai retrograde audacity de la version Sid vers la version de Lenny ainsi :
Apres il faut bloquer la mise a jour du paquet pour eviter qu’il ne soit remis a niveau. Il y a plusieures possibilites : aptitude hold, fichier preferences, etc…
Ce que je diasais avait deja ete evoque rapidement dans ce meme fil ici effectivement.
[quote]Merci youki.
mai tu croit que c est possible si un paquet a beaucoup de descendance genre dbus ?[/quote]
Ben je suis pas encore assez expert en la matiere pour affirmer quoi que ce soit, donc a ce qui suit est a prendre avec des pincettes et a verifier.
Il me semble que (mais c’est empirique, je le rappelle) :
# echo “nom_du_paquet hold”|dpkg --set-selections ne bloque que le paquet indique. # aptitude hold nom_du_paquet bloque le paquet et ses dependances.
Sinon, il faut mettre les paquets que tu veux bloquer dans le fichier preferences avec une priorite negative, mais j’utilise jamais cette solution donc je sais encore mons gerer les dependances dans ce cas.
Ça dépend. Si tu ne veux pas la version superieur tu la « pin » à -1, si tu veut plutôt garder la version actuelle tu la « pin » à 1001.
La gestion des dépendances dans ce cas ne pose pas de problèmes. apt-get/aptitude vont effectuer leur calcul de dépendances en prenant en compte le fait que cette version est à garder ou au constraire à proscrire. Prenons un paquet A positionner à 1001 et dépendant d’un paquet B. Si le paquet A indique qu’il a besoin d’une version sperieur ou égale à 1.0, alors le paquet B pourras être mis à jour sans problème.
. Evidemment, il y a le souci de la libc6, on peut soit se rabattre sur une autre origine (le volatile), soit essayer d’utiliser aptitude qui est plus futé qu’apt-get dans ce genre de cas:
).
).
[/size]
