Pourquoi les preferences du T&A sont foireux ?

Pause Café
#1

Ce sujet fait suite à la demande de Ricardo d’ouvrir un débat à ce propos.

Sous ce titre un brin provocateur se cache une bien triste réalité : les preferences du T&A sont néfastes pour votre système. Mais pourquoi donc ?

Dans un message aux sujet d’apt.preferences j’ai donné quelques règles à observer pour construire des preferences neutres, génériques et facilement adaptables. Je ne m’attarderai ici qu’à la première règle, à savoir :

« 1) Garder des priorité identiques pour les dépôts Debian officiels d’une même branche. C’est le comportement par défaut (ex : quand l’on a que les dépôts de la branche suivie sans preferences). Tout manquement à cette règle casse le comportement par defaut et peut générer des résultats très dommageables car non prévus par les devs Debian. »

Cette règle n’est pas respectée par les preferences du T&A : les dépôts Security et Volatile ont une priorité supérieure aux autres dépôts officiels d’une même branche, ce qui casse le comportement par défaut des mises à jours et provoque des résultats très pervers !

  • Stable :
    La branche Stable bénéficie régulièrement de mises à jours intermédiaires incrémentant son numéro de version (à ce jour 5.0.3). Ces MàJ sont destinées à corriger des bogues et des problèmes de sécurité. On peut trouver la liste des MàJ pour la 5.0.3 ici.

Prenons l’exemple de Pidgin :

$ apt-cache policy pidgin
pidgin:
  Installé : 2.4.3-4lenny1~volatile0
  Candidat : 2.4.3-4lenny1~volatile0
 Table de version :
     2.6.2-1 0
        95 http://ftp.fr.debian.org sid/main Packages
     2.6.1-2 0
        97 http://ftp.fr.debian.org squeeze/main Packages
     2.4.3-4lenny4 0
        986 http://ftp.fr.debian.org lenny/main Packages
     2.4.3-4lenny3+b1 0
        987 http://security.debian.org lenny/updates/main Packages
 *** 2.4.3-4lenny1~volatile0
        988 http://volatile.debian.org/debian-volatile/main Packages
        100 /var/lib/dpkg/status

La version candidate et installée est donc une version obsolète (2.4.3-4lenny1~volatile0) alors que la dernière version disponible pour ceux qui n’ont pas de preferences ou qui ont un preferences propre est la 2.4.3-4lenny4 qui corrige plusieurs bogues et vulnérabilités :

packages.qa.debian.org/p/pidgin/ … 0446Z.html
packages.qa.debian.org/p/pidgin/ … 0249Z.html
packages.qa.debian.org/p/pidgin/ … 3241Z.html

Un autre exemple avec le noyau :

$ apt-cache policy linux-image-2.6.26-2-amd64
linux-image-2.6.26-2-amd64:
  Installé : 2.6.26-17lenny2
  Candidat : 2.6.26-17lenny2
 Table de version :
     2.6.26-19 0
        986 http://ftp.fr.debian.org lenny/main Packages
 *** 2.6.26-17lenny2 0
        987 http://security.debian.org lenny/updates/main Packages
        100 /var/lib/dpkg/status

Pourtant la version 2.6.26-19 corrige :

packages.qa.debian.org/l/linux-2 … 3219Z.html

Et si l’on se réfère à cette page concernant la vulnérabilité CVE-2009-2846 on voit bien que le noyau 2.6.26-17lenny2 y est vulnérable :

Source Package  Release	         Version                Status
linux-2.6 (PTS) etch             2.6.18.dfsg.1-24       vulnerable
                etch (security)  2.6.18.dfsg.1-24etch4  fixed
                etch-backports   2.6.26-13~bpo40+1      vulnerable
                lenny (security) 2.6.26-17lenny2        vulnerable
                lenny            2.6.26-19              fixed
                squeeze, sid     2.6.30-6               fixed
                lenny-backports  2.6.30-6~bpo50+1       fixed

Même chose pour les 3 autres vulnérabilités… Mettre une priorité supérieure au dépôts Security n’est donc pas un gage de sécurité, bien au contraire !

  • Testing
    C’est la même chose mais de façon beaucoup plus prononcé encore de par sa nature très changeante et du fait que la plupart des MàJ de sécurité arrivent directement de Sid. Des paquets aux versions obsolètes et troués comme de l’emmental peuvent rester de longs mois dans les dépôts Security, comme par exemple Iceweasel du temps où Lenny était en Testing.

Pour finir, tout ceci n’est qu’un petit aperçu des problèmes qu’engendre les preferences du T&A car, du fait des dépendances, les blocages de versions qu’engendrent ces preferences peuvent bloquer de nombreux paquets et empêcher leur MàJ/installation, ce qui non seulement est ennuyeux pour l’utilisateur/administrateur mais casse aussi la cohérence du système et réduit de ce fait sa fiabilité. Et tout cela sans même installer un seul paquet d’une autre branche…

PS. Mélanger Stable avec les autres branches est souvent une très mauvaise idée. Si vous avez besoin de paquets plus récents préférez les Backports (mais n’en abusez pas !), la compilation ou utilisez une autre branche (Testing/Sid) !

EDIT : Légère modif. du PS

#2

Salut,
Je suis ravi de te lire… Je n’ai jamais compris l’utilité du fichier préférences et du mélange des branches…
La seule fois ou je me suis aventuré dans cette voie… (Uniquement parce que le fil dont nous parlons tient le haut du pavé dans T&A… donc il est important :smt003 ) ça a été la catastrophe… Je suis vite revenu en arrière !
Il faut faire son choix, et s’y tenir, question de bon sens. C’est évidemment “techniquement” léger comme argument, mais il en vaut d’autres !
Quand on installe Debian, il n’est pas question de préférence… :wink:

Edit : Ce sujet mérite mieux que pause-café !

#3

Les paquets du depot security.debian.org sont censés être plus surs que les paquets du dépots standard. Ce que tu signales est un pbm relativement nouveau mais réel. La prédominance des paquets security sur les dépots a longtemps été recommandé.

C’est dommage que le débat se soit fait de façon conflictuel sur ce fichiers preferences: j’ai lu plusieurs fil où tu critiquais le fichier preferences mais un seul (sauf celui là) où ton objection était expliquée. Car ça mérite d’être dans le T&A…

En fait il suffit de mettre les preferences comme suit pour Lenny

[code]Package: *
Pin: release o=apt-build
Pin-Priority: 990

Package: *
Pin: release o=volatile.debian.org,a=stable,l=debian-volatile
Pin-Priority: 990

Package: *
Pin: release o=Debian,a=stable,l=Debian-Security
Pin-Priority: 990

Package: *
Pin: release o=Unofficial Multimedia Packages,a=stable,l=Unofficial Multimedia Packages
Pin-Priority: 990

Package: *
Pin: release o=Debian,a=stable,l=Debian
Pin-Priority: 990

Package: *
Pin: release o=Debian,a=testing,l=Debian-Security
Pin-Priority: 90

Package: *
Pin: release o=Unofficial Multimedia Packages,a=testing,l=Unofficial Multimedia Packages
Pin-Priority: 90

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

Package: *
Pin: release o=Unofficial Multimedia Packages,a=unstable,l=Unofficial Multimedia Packages
Pin-Priority: 50

Package: *
Pin: release o=Debian,a=unstable,l=Debian
Pin-Priority: 50

Package: *
Pin: release o=Unofficial Multimedia Packages,a=experimental,l=Unofficial Multimedia Packages
Pin-Priority: 10

Package: *
Pin: release o=Debian,a=experimental,l=Debian
Pin-Priority: 10[/code]

Je ne conseille pas forcément l’usage intensif de backport: Cela peut induire des problèmes dans une mise à jour vers une nouvelle stable: le backport est une version plus récente donc s’impose et ses dépendances nécessitent des paquets de la vieille stable incompatibles avec la mise à jour. J’ai installé par première Debian en 1997 et n’ai réinstallé une machine qu’une fois à cause d’un mélimélo suite à usage intensifs de backports (et d’une impatience coupable, ça n’était pas indispensable).

#4

Salut François,

Je l’ai constaté depuis Etch, mais ne peux me prononcer pour les versions antérieures que je n’ai pas pratiquées… :blush:

Là je n’ai jamais rien vu à ce sujet mais je comme je ne pratique Debian que depuis les débuts d’Etch…

J’ai en effet fait ce constat de nombreuses fois en développant plus ou moins mon propos de façons souvent maladroites et provocatrices (il faut dire que toutes les conséquences ne sont pas observables/vérifiables en permanence), mais c’est la première fois que je le développe autant (bien qu’il pourrait l’être beaucoup plus).

Par exemple ou comme ici (c’est peu ou prou la même chose).

Oui, d’ailleurs il me semble qu’ils prennent soins de mettre en garde les utilisateurs à ce sujet. Si un jours les Backports rentrent officiellement dans Debian il en sera peut être autrement…

#5

Note que c’était une machine sous sarge avec énormément de backports perso, ce qui explique les pbms. apt est apparu assez vite avec la slink (avant c’était dselect et dpkg) mais n’est devenu vraiment pratique qu’avec potato. Je n’ai découvert les preferences que très récemment (sarge/etch). Je n’ai pas l’impression qu’il y avait des mises à jour de la stable du type de celle du 7 septembre (des paquets par dizaine…).

#6

@ fran.b: dans ton fichier de pref, t’as :

[code]Package: *
Pin: release o=Unofficial Multimedia Packages,a=stable,l=Unofficial Multimedia Packages
Pin-Priority: 990

Package: *
Pin: release o=Debian,a=stable,l=Debian
Pin-Priority: 990[/code]
Donc, au prochain upgrade, les gars qui avaient résolu le pb de vlc (dû au libavcodec51 et autres de multimedia) se retrouveront avec le même pb: il faut baisser ,pour lenny en tout cas, les prio de multimedia.

#7

Ah ah, je l’attendais celle là, à priorité égale, l’ordre des dépots pris en compte est celui du fichiers sources.list où les dépots de Marillat sont rajoutés. Ce fichier preferences est la reprise de celui du T&A avec le sources.list correspondant. Ça devrait marcher. J’ai mis les mêmes priorités pour aller au bout de l’idée de … (tu parles d’un pseudo!): mettre des priorités identiques autant que faire se peut sur les dépot officiels Debian d’une même branche. On voit ici que je considère les dépots de Marillat comme officiels. Mais tu as raison, ça se discute… (En clair, j’ai été vite et n’ai guère fait attention à ce point, j’arrive a posteriori à le justifier mais c’est peut être une mauvaise idée…).

PS: Ce pbm subsiste-t-il avec le passage à la 5.03? si oui, je trouverais ça décevant…

[edit: Tu as raison et j’ai dit une c…e:

[quote] · Quand deux (ou plus) versions ont la même priorité et le même numéro de version, mais soit les paquets diffèrent par certaines métadonnées, soit loption
–reinstall a été donnée, installer la version qui nest pas installée.
[/quote]

Il faudrait également indiqué comment forcer un retour à une version antérieure de la distribution (typiquement revenir à Stable: pour cela mettre les préférences des dépots stable à 1010 convient et marche très bien]

#8

Je croyais que l’ordre de sources.list indiquait l’ordre de préférence des miroirs, pas des dépôts. On peut mettre plusieurs miroirs pour un même dépôt pour la redondance, mais ça ne veut pas dire que les paquets de l’un sont prioritaires sur les paquets de l’autre. C’est juste le premier miroir disponible (de préférence le plus proche, avec la meilleure bande passante…) qui est utilisé.

Quel est l’intérêt ?

#9

Salut,

  1. C’est les mainteneurs Debian de VLC qui l’on rendu incompatible avec les dépôts Multimédia. D’ailleurs l’histoire VLC-Multimédia est plutôt pitoyable…
  2. Dans un preferences générique on ne peut s’adapter à chaque cas particulier.
  3. (mon avis) Pour le problème VLC il n’y a pas qu’une seule solution. Celles de baisser la prio du dépôts multimédia en est une mais ce n’est pas non plus la panacée. Autant rester dans l’esprit de départ, quitte à mettre un avertissement.
#10

C’est bien d’avoir un sujet pour expliquer un peu les affirmatio que tu faisais. Seulement, tu poses le débats sur des considérations purement techniques…

Hors la nécessité d’installer des paquets d’une version récentes sur une debian stable peut-être purement pratique. Je suis prof, avec mes collègues ont utilise OOo (j’ai réussi à les convaincre), seulement ils sont restés sur w$ - Donc si j’en reste à OOo lenny, je suis avec la version 2.4 (je crois) - Eux bien entendu vont avoir dans les mains la version 3.1, pour la compatibilité des documents c’est pas vraiment idéal tu en conviendras. Cependant, et la question est ; Dois-je pour autant mettre ma machine sur un noyau et d’autres paquets (apache par ex.) en moins stable juste parce que mon OOo ne serait pas compatible pour travailler ?

#11

Effectivement, ça peut poser problème si tu veux installer un programme du dépôt multimedia qui dépend des mêmes libs, par exemple ffmpeg[*] ou avidemux. Aptitude proposera comme solution de prendre les libs dans le dépôt multimedia malgré leur priorité plus faible.
Une autre solution est de prendre une version de vlc > 1.0.1 (dépôts testing, sid ou nighty builds) qui fonctionne avec les libs du dépôt multimedia.

[*] On trouve aussi ffmpeg dans les dépôts officiels, mais il est plus limité.

Si on en vient à modifier le T&A, il serait peut-être bon de faire une remarque au début pour les débutants. J’ai l’impression que certains recopient le sources.list et le preferences (ou pas) sans rien comprendre alors qu’ils pourraient se contenter d’une seule branche sans fichier preferences (à moins de vouloir être en stable et utiliser vlc :smiley: ). On peut aussi signaler que si on veut se contenter d’une seule branche, il vaut mieux éviter testing.
De plus, on a rarement besoin de toutes les branches. En somme le T&A est plus utile comme aide pour construire son preferences que comme exemple à suivre à la lettre. Il faudrait AMHA insister un peu plus là dessus…

#12

:smt006

Dommage que Matt ne soit pas ici (ça fait un moment d’ailleurs …) puisqu’il est l’auteur de ce T&A et qu’il doit avoir des arguments à présenter … (quelqu’un a des nouvelles au fait ?)

#13

Effectivement, ça peut poser problème si tu veux installer un programme du dépôt multimedia qui dépend des mêmes libs, par exemple ffmpeg[*] ou avidemux. Aptitude proposera comme solution de prendre les libs dans le dépôt multimedia malgré leur priorité plus faible.
Une autre solution est de prendre une version de vlc > 1.0.1 (dépôts testing, sid ou nighty builds) qui fonctionne avec les libs du dépôt multimedia.

[*] On trouve aussi ffmpeg dans les dépôts officiels, mais il est plus limité.

Si on en vient à modifier le T&A, il serait peut-être bon de faire une remarque au début pour les débutants. J’ai l’impression que certains recopient le sources.list et le preferences (ou pas) sans rien comprendre alors qu’ils pourraient se contenter d’une seule branche sans fichier preferences (à moins de vouloir être en stable et utiliser vlc :smiley: ). On peut aussi signaler que si on veut se contenter d’une seule branche, il vaut mieux éviter testing.
De plus, on a rarement besoin de toutes les branches. En somme le T&A est plus utile comme aide pour construire son preferences que comme exemple à suivre à la lettre. Il faudrait AMHA insister un peu plus là dessus…[/quote]

+1 mais bon ah ah ah ah tu demande à ce que les gens lisent les manuels et s’en inspirent ( merdum … je croyais justement qu’un tutoriel hormis chez Ubuntu était là pour s’inspirer afin de résoudre des problèmes) .
Rien qu’a voir la façon dont les gens demandent de l’aide en étant systématiquement désespéré et ne vont simplement qu’effectué du copier collé afin de résoudre leur problème sans jamais rien comprendre à ce qu’ils ont fait.

#14

Salut,

Excellente remarque, que j’étofferais en disant (très gentiment) que même ceux qui savent…ne savent pas toujours vraiment ! :mrgreen:

Je sais parfaitement que venir mettre mon grain de sel dans cette discussion ne doit pas être apprécié par tout le monde… (j’ai parfois l’impression d’être dans la liste d’ignoré de pas mal de monde :laughing: Je sais que ce n’est pas vrai, mais sur certains sujets, c’est tout pareil ! :wink:

Je voudrais aussi faire remarquer que SID est stable, et ne doit pas faire peur à un utilisateur moyennement expérimenté. Je m’en sort très bien…
Tu veux du logiciel récent ? Accepte les contraintes et les risques ! C’est toujours plus stable d’avoir une vraie SID qu’une LENNY branlante…

Jouer aux apprentis sorciers avec les dépôts de différentes branches n’est pas une bonne idée - selon moi ! :smt006

#15

[quote=“lol”]Salut,

Je voudrais aussi faire remarquer que SID est stable, …[/quote]
Unstable.
Tout dépend du sens de stable. Elle est “unstable” dans le sens où la version des paquets n’est pas figée. Si on parle de stable au sens de non-buguée, elle est aussi stable que la dernière *buntu. :smt003

#16

[quote=“Junichirô”][quote=“lol”]Salut,

Je voudrais aussi faire remarquer que SID est stable, …[/quote]
Unstable.
Tout dépend du sens de stable. Elle est “unstable” dans le sens où la version des paquets n’est pas figée. Si on parle de stable au sens de non-buguée, elle est aussi stable que la dernière *buntu. :smt003[/quote]Oui, tu m’as parfaitement compris. Elle n’est pas dans la branche “stable”, mais elle parfaitement stable dans le sens ou elle ne plante jamais…
Je m’excuse humblement d’avoir abusivement et à mauvais escient employé le mot “stable” :wink:

#17

Installe OO 3.1! en ce qui me concerne, j’ai installé les paquets fournis par Openoffice.org…

Pour vlc, j’ai résolu le pbm en recompilant le paquet avec les librairies de vlc multimedia.

#18

D’autant qu’il y a deux jours ce fut la vrai merde avec les backports sur 32 bits! J’ai un petit fichier preferences pour les mises à jour de Backports et ces cons n’ont pas remplacé tous les paquets anciens par les nouveaux le même jour. :angry:

Sur Blag je l’installe à partir du paquet fourni par OOO.org sans problème.

#19

Installe OO 3.1! en ce qui me concerne, j’ai installé les paquets fournis par Openoffice.org…

Pour vlc, j’ai résolu le pbm en recompilant le paquet avec les librairies de vlc multimedia.[/quote]
Oui, oui, j’ai installé OOo-3.1 - Mais il s’agissait d’expliquer pourquoi l’utilisation des préférences pour le simple utilisateur ne se limitait pas à un problème technique.

Une autre remarque à ceux qui prétendre que sid (unstable) est stable. Il faut largement nuancé l’utilisation de sid par les newbies, parce que si parallèlement ils usent et abusent de “update” et “dist-upgrade” ils risquent d’avoir de drôles de surprises si les paquets ne sont pas tous libérés.

#20

[quote=“sebiseb”]Oui, oui, j’ai installé OOo-3.1 - Mais il s’agissait d’expliquer pourquoi l’utilisation des préférences pour le simple utilisateur ne se limitait pas à un problème technique.

Une autre remarque à ceux qui prétendre que sid (unstable) est stable. Il faut largement nuancé l’utilisation de sid par les newbies, parce que si parallèlement ils usent et abusent de “update” et “dist-upgrade” ils risquent d’avoir de drôles de surprises si les paquets ne sont pas tous libérés.[/quote]
C’est surtout que la définition de «stable» est variable: Etch était (et est) fiable, quasi un modèle. La lenny n’est pas un modèle du genre loin de là, beaucoup de souci imposant le retour à des paquets de Etch (dont certains importants par exemple iceweasel qui sur une lenny pure fige lorsqu’on demande une impression). La Sid n’est pas raisonnablement utilisable sur une machine de travail. Sur ma machine (lenny) j’ai des paquets Etch et d’autres des backports perso. Les préférences m’ont parfois amené à privilégier Etch sur Lenny sur certains paquets afin de remédier à des bugs.