Priorités négatives dans les preferences?

Salut,

Après plusieurs heures de recherche et de lecture je ne trouve pas de réponse claire à ma question…
Les priorités strictement négatives ne semblent pas fonctionner pour un paquet.
Ex de scénario:
-> Je ne veux pas d’un paquet, je lui colle une prio négative. Résultat : il s’en fout, il veut m’installer le paquet si je tappe apt-get install . Par contre si je lui met la prio 1001 c’est bon. Premio je vois pas pourquoi ca résoud le probleme, secondo, ca ne marche pas chez tout le monde, je ne sais pas exactement pourquoi.
-> Je veux eviter une version . Je suis en version 1 de trucmuche, je sais que la version 2 plante mon système. Par contre je veux pouvoir installer automatiquement la version 3 dès qu’elle est dispo. Donc le hold est pas envisageable.

Il y a des bugs concernant cette fonctionnalités qui datent de plusieurs centaines de jours mais pas de réponses claires.

Une idée :question:

tu as deux choses: le pattern, et la prio.
Si tu as des sources une avec la version de paquet que tu veux, et l’autre avec celle que tu refuse, tu mets déjà des priorités aux deux (autres que 500, pour bien voir) et tu regardes avec 'apt-cache policy ’ si les patterns sont bien corrects et s’ils ont bien les prios que tu attends.
Ensuite, tu fixes les prios que tu veux. <0 doit désinstallé les versions de paquets qu’il matche et >1000 doit forcer l’install.
Tu peux être plus précis, et donner le résultat d’apt-cache policy ’ du paquet qui t’ennuie, ainsi que les sections de tes preferences qui sont censées leur affecter une prio ?

[code]debian:~# more /etc/apt/preferences
explanation: defaut
Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 600

Package: *
Pin: release o=Debian,a=testing
Pin-Priority: 500

Package: *
Pin: release a=experimental
Pin-Priority: 9[/code]

debian:~# pol autofs autofs: Installé : (aucun) Candidat : 4.1.4-9 Table de version : 4.1.4-9 0 500 http://http.us.debian.org testing/main Packages 600 http://http.us.debian.org unstable/main Packages 4.1.3+4.1.4beta2-10 0 500 http://http.us.debian.org stable/main Packages

J’edite le petit preferences, je rajoute ca:

Package: autofs Pin: release a=* Pin-Priority: -10

et la:

debian:~# apt-get -s install autofs Lecture des listes de paquets... Fait Construction de l'arbre des dépendances... Fait Paquets recommandés : nfs-common Les NOUVEAUX paquets suivants seront installés : autofs 0 mis à jour, 1 nouvellement installés, 0 à enlever et 1 non mis à jour. Inst autofs (4.1.4-9 Debian:testing) Conf autofs (4.1.4-9 Debian:testing)

debian:~# !pol
pol autofs
autofs:
  Installé : (aucun)
  Candidat : 4.1.4-9
  Étiquette de paquet : (non trouvé)
 Table de version :
     4.1.4-9 -10
        500 http://http.us.debian.org testing/main Packages
        600 http://http.us.debian.org unstable/main Packages
     4.1.3+4.1.4beta2-10 -10
        500 http://http.us.debian.org stable/main Packages

Et si je mets 1001:

debian:~# pol autofs autofs: Installé : (aucun) Candidat : (aucun) Étiquette de paquet : (non trouvé) Table de version : 4.1.4-9 1001 500 http://http.us.debian.org testing/main Packages 600 http://http.us.debian.org unstable/main Packages 4.1.3+4.1.4beta2-10 1001 500 http://http.us.debian.org stable/main Packages

debian:~# apt-get -s install autofs
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Aucune version du paquet autofs n'est disponible, mais il existe dans la base
de données. Cela signifie en général que le paquet est manquant, qu'il est devenu obsolète
ou qu'il n'est disponible que sur une autre source
E: Aucun paquet ne correspond au paquet autofs

La ca a bien fait ce que je voulais.
Merci

apt-get --remove paquetdontjeneveuxpas

Bon, tu as raison, je n’avais jamais fait de pinning de paquet individuel, mais quoi que j’essayes chez moi avec autofs, ça ne marche pas (en le mettant avant, en mettant “autofs*”, etc). Je remarque que la prio est reportée à coté du numero de version, mais ça n’a aucun effet, et le pinning lié à la distrib reste dominant.
Alors il y a un contournement avec aptitude, en attendant de savoir comment faire un bon pinning:[quote=“man aptitude”] forbid-version
Empêche la mise à jour vers une version précise d’un paquet. Cette option interdit à aptitude la mise à jour automatique vers cette ver-
sion, mais permettra le passage aux versions suivantes. Par défaut, aptitude choisira la version vers laquelle ce paquet aurait normale-
ment dû être mis à jour. Vous pouvez modifier ce choix en ajoutant « » au nom du paquet: par exemple, « aptitude forbid-ver-
sion vim=1.2.3.broken-4 ».

          Cette commande est pratique pour éviter les versions boguées des paquets sans avoir à définir ou supprimer des gels à la main.  Si  vous
          décidez finalement d'installer la version que vous aviez interdite, la commande « install » mettra fin à l'interdiction.

[/quote]

Ah oui c’est deja tres utile cette commande ca resoud le scenario 2, qui est le plus réaliste.
Reste le scenario 1, ex: paquet_a_installer depend de paquetbuggé|paquet_alternatif et que paquetbuggé n’existe sous aucune version sur mon système.
Je veux bien qu’il ne soit pas possible de faire ce que je demande mais dans ce cas là, pourquoi le man page en parle… bizarre.

Merci

je pense qu’il y a une erreur sur la manière de déclarer le pinning d’un seul paquet: nous sommes parti sur une config similaire à celle des lots de paquets, mais il doit y avoir une subtilité.
En attendant, je n’ai pas trop compris ton exemple de ce que tu n’arrives pas à faire maintenant… :wink:
Parceque si j’ai bien compris, je ne vois pas en quoi ça pose pb: ça va installer paquet_a_installer+paquet_alternatif, non ?

[quote=“MattOTop”]je pense qu’il y a une erreur sur la manière de déclarer le pinning d’un seul paquet: nous sommes parti sur une config similaire à celle des lots de paquets, mais il doit y avoir une subtilité.
[/quote]
Oui je vais gratter encore un peu mais sinon je laisse tomber, c’est pas primordial… Parceque ca se saurait s’il y avait des paquets buggés sous debian :slightly_smiling:

[quote]
En attendant, je n’ai pas trop compris ton exemple de ce que tu n’arrives pas à faire maintenant… :wink:
Parceque si j’ai bien compris, je ne vois pas en quoi ça pose pb: ça va installer paquet_a_installer+paquet_alternatif, non ?[/quote]

Ben le truc c’est que ce que tu m’as filé marche très bien, dès lors qu’au moins une version est installée. Mais si aucune version n’est installée, pas moyen de bloquer l’installation du paquet.

ps: sinon le coup de la prio à 1001 marche chez moi… mais je sais pas pourquoi lol
pas grave…

bonjour,
effectivement, j’ai aussi essayé différentes solution pour empêcher l’installation d’un paquet, mettons autofs, qui chez moi n’est pas installé, et la simulation d’apt-get me notifie toujours une installation du paquet, sarge pour moi, ou sid si j’enlève la directive APT::Defaut-Release “stable” dans le fichiers /etc/apt/apt.conf.d/99localPerso (chez moi).
Les voix d’apt-get seraient-elles impénétrables … En tout cas ça m’a fait du bien de lire :
http://www.debian.org/doc/manuals/apt-howto/index.fr.html#contents
même si les subtilités m’échappent allègrement …
mais j’ai noté en essayant deux trois trucs que :

  • il semblerait qu’il vaut mieux déclarer un package en fin de fichier preferences si on veut un traitement spécifique à celui-ci …
  • que si on peut utiliser la terminologie sarge / etch / sid dans sources.list,
    son usage dans preferences ne produit pas du tout le même effet …
  • il semble qu’à chaque modification de preferences ou de sources.list, un update est bien venu … ( me trompe-je pour preferences ? )
  • qu’on peut spécifier une version par Pin: release v=4.1.5*, a=unstable par exemple, mais là j’avoue ne pas comprendre pourquoi des fois, un apt-cache policy affiche Etiquette: (non trouvé) alors qu’elle est correcte …
    Enfin, puissant mais subtil, apt-get …

Merci de t’^etre penché sur le problème, depuis j’ai un peu abandonné…
Oui effectivement le coup de l’etiquette invalide m’a étonné.
Et oui j’ai remarqué qu’il faut parfois faire un apt-get update après modif de preferences sinon ce n’est pas pris en compte… pour sources.list c’est clair il faut le faire. En gros maintenant, je le fait a chaque modif d’un de ces deux fichiers.

Mystère et boule de gomme…

Je ne compreds pas bien ce que tu veux exactement :.

donc il ne te l’installe pas :question:

explique-moi pourquoi tu ne veux pas d’un paquet et que tu tapes :
apt-get install
:question: :question: :question:
peut-être veux-tu parler de ‘version’ et non de ‘paquet’ :question:
Ds ce cas, si, comme tu dis plus bas, tu as la version 1 qui fonctionne, la version 2 qui ne fonctionne pas et tu attends la version 3 qui, il te semble, va fonctioinner,
va sur Synaptic :
"installé pouvant être mis à jour"
et quand tu verras la version 3 présente, tu l’installes et seulement celle-là.[/code]

[quote=“ricardo”]Je ne compreds pas bien ce que tu veux exactement :.

donc il ne te l’installe pas :question:
[/quote]
Ben si

Je suis étonné que cette question me soit pas arrivée avant :slightly_smiling: Non je ne suis pas schyzophrène, je veux juste verifier le fonctionnement des preferences. Simple check :wink:
Imagine le cas: j’ai un paquet A qui depend de B(b comme buggé ca tombe bien) ou C (B|C alternative).
J’installe A, je ne veux pas qu’il m’installe B mais C.

[quote]
peut-être veux-tu parler de ‘version’ et non de ‘paquet’ :question:
Ds ce cas, si, comme tu dis plus bas, tu as la version 1 qui fonctionne, la version 2 qui ne fonctionne pas et tu attends la version 3 qui, il te semble, va fonctioinner,
va sur Synaptic :
"installé pouvant être mis à jour"
et quand tu verras la version 3 présente, tu l’installes et seulement celle-là.[/code][/quote]
J’ai pas toujours x-window et j’utilise soit apt soit aptitude.
De plus je veux que ce soit automatique, pas à verifier tous les jours si la version 3 arrive…

On contourne le problème là…