Je suis actuellement en Sid, et si, pour l'instant ça se passe bien, je
ne ressent finalement pas du tout le besoin d'avoir les tous derniers
paquets tout de suite.
En revanche, je ne fais pas les mise-à-jour très fréquemment, ce qui
n'est pas forcément un comportement très sain avec Sid :-)
Et pour la continuité des services que je fais tourner sur ma machine
(principalement des conteneurs dockers pour mon réseau local/usage
privé), je souhaiterais revenir sur (au moins) du testing.
Aussi, j'aimerais repasser à Stretch (et peut-être y attendre sagement
le freeze pour repasser en stable avec la release), mais sans
réinstallation ce serait encore mieux.
Je voulais savoir si en mettant mes sources.list en testing, et en ne
faisant jamais au grand jamais de dist-upgrade, j'avais une change de
repasser en "testing pur", sans perte ni fracas ?
Si vous avez d'autres idées avec plaisir, toujours est-il
qu'aujourd'hui, ma Debian n'a pas de bug pour mon utilisation, donc je
n'ai pas besoin d'un downgrade qui se fait le temps d'une nuit blanche,
mais je me contente très bien d'un downgrade progressif.
Bonjour, Je suis actuellement en Sid, et si, pour l'instant ça se passe bien, je ne ressent finalement pas du tout le besoin d'avoir les tous derniers paquets tout de suite. En revanche, je ne fais pas les mise-à-jour très fréquemment, ce qui n'est pas forcément un comportement très sain avec Sid :-) Et pour la continuité des services que je fais tourner sur ma machine (principalement des conteneurs dockers pour mon réseau local/usage privé), je souhaiterais revenir sur (au moins) du testing. Aussi, j'aimerais repasser à Stretch (et peut-être y attendre sagement le freeze pour repasser en stable avec la release), mais sans réinstallation ce serait encore mieux. Je voulais savoir si en mettant mes sources.list en testing, et en ne faisant jamais au grand jamais de dist-upgrade, j'avais une change de repasser en "testing pur", sans perte ni fracas ? Si vous avez d'autres idées avec plaisir, toujours est-il qu'aujourd'hui, ma Debian n'a pas de bug pour mon utilisation, donc je n'ai pas besoin d'un downgrade qui se fait le temps d'une nuit blanche, mais je me contente très bien d'un downgrade progressif. Merci par avance, Damien T
Bonsoir, Je ne comprends pas trop le problème. En mettant les dépôts de stable, testing et unstable avec un pinning sur testing, tu vas passer progressivement de unstable à testing. Normalement sans douleur. Cordialement, JKB
Damien TOURDE a écrit :
Bonjour,
Je suis actuellement en Sid, et si, pour l'instant ça se passe bien, je
ne ressent finalement pas du tout le besoin d'avoir les tous derniers
paquets tout de suite.
En revanche, je ne fais pas les mise-à-jour très fréquemment, ce qui
n'est pas forcément un comportement très sain avec Sid :-)
Et pour la continuité des services que je fais tourner sur ma machine
(principalement des conteneurs dockers pour mon réseau local/usage
privé), je souhaiterais revenir sur (au moins) du testing.
Aussi, j'aimerais repasser à Stretch (et peut-être y attendre sagement
le freeze pour repasser en stable avec la release), mais sans
réinstallation ce serait encore mieux.
Je voulais savoir si en mettant mes sources.list en testing, et en ne
faisant jamais au grand jamais de dist-upgrade, j'avais une change de
repasser en "testing pur", sans perte ni fracas ?
Si vous avez d'autres idées avec plaisir, toujours est-il
qu'aujourd'hui, ma Debian n'a pas de bug pour mon utilisation, donc je
n'ai pas besoin d'un downgrade qui se fait le temps d'une nuit blanche,
mais je me contente très bien d'un downgrade progressif.
Merci par avance,
Damien T
Bonsoir,
Je ne comprends pas trop le problème. En mettant les dépôts de stable,
testing et unstable avec un pinning sur testing, tu vas passer
progressivement de unstable à testing. Normalement sans douleur.
Bonjour, Je suis actuellement en Sid, et si, pour l'instant ça se passe bien, je ne ressent finalement pas du tout le besoin d'avoir les tous derniers paquets tout de suite. En revanche, je ne fais pas les mise-à-jour très fréquemment, ce qui n'est pas forcément un comportement très sain avec Sid :-) Et pour la continuité des services que je fais tourner sur ma machine (principalement des conteneurs dockers pour mon réseau local/usage privé), je souhaiterais revenir sur (au moins) du testing. Aussi, j'aimerais repasser à Stretch (et peut-être y attendre sagement le freeze pour repasser en stable avec la release), mais sans réinstallation ce serait encore mieux. Je voulais savoir si en mettant mes sources.list en testing, et en ne faisant jamais au grand jamais de dist-upgrade, j'avais une change de repasser en "testing pur", sans perte ni fracas ? Si vous avez d'autres idées avec plaisir, toujours est-il qu'aujourd'hui, ma Debian n'a pas de bug pour mon utilisation, donc je n'ai pas besoin d'un downgrade qui se fait le temps d'une nuit blanche, mais je me contente très bien d'un downgrade progressif. Merci par avance, Damien T
Bonsoir, Je ne comprends pas trop le problème. En mettant les dépôts de stable, testing et unstable avec un pinning sur testing, tu vas passer progressivement de unstable à testing. Normalement sans douleur. Cordialement, JKB
Damien TOURDE
Le lundi 22 août 2016 à 22:55 +0200, BERTRAND Joël a écrit :
Bonsoir, Je ne comprends pas trop le problème. En mettant les dépôts de stable, testing et unstable avec un pinning sur testing, tu vas passer progressivement de unstable à testing. Normalement sans douleur. Cordialement, JKB
Quelle serait la différence entre les 3 dépôts + pinning testing et simplement n'avoir que des références à testing ? La peur que j'ai c'est qu'il me downgrade les paquets au lieu de simplement attendre que testing ait rattrapé ma version de sid (en gros sid au 20/08/2016). Car d'après la doc Debian, les scripts d'installation ne sont pas du tout prévu pour un downgrade des paquets. Merci, Damien
Le lundi 22 août 2016 à 22:55 +0200, BERTRAND Joël a écrit :
Bonsoir,
Je ne comprends pas trop le problème. En mettant les dépôts de
stable,
testing et unstable avec un pinning sur testing, tu vas passer
progressivement de unstable à testing. Normalement sans douleur.
Cordialement,
JKB
Quelle serait la différence entre les 3 dépôts + pinning testing et
simplement n'avoir que des références à testing ?
La peur que j'ai c'est qu'il me downgrade les paquets au lieu de
simplement attendre que testing ait rattrapé ma version de sid (en gros
sid au 20/08/2016).
Car d'après la doc Debian, les scripts d'installation ne sont pas du
tout prévu pour un downgrade des paquets.
Le lundi 22 août 2016 à 22:55 +0200, BERTRAND Joël a écrit :
Bonsoir, Je ne comprends pas trop le problème. En mettant les dépôts de stable, testing et unstable avec un pinning sur testing, tu vas passer progressivement de unstable à testing. Normalement sans douleur. Cordialement, JKB
Quelle serait la différence entre les 3 dépôts + pinning testing et simplement n'avoir que des références à testing ? La peur que j'ai c'est qu'il me downgrade les paquets au lieu de simplement attendre que testing ait rattrapé ma version de sid (en gros sid au 20/08/2016). Car d'après la doc Debian, les scripts d'installation ne sont pas du tout prévu pour un downgrade des paquets. Merci, Damien
BERTRAND Joël
Damien TOURDE a écrit :
Le lundi 22 août 2016 à 22:55 +0200, BERTRAND Joël a écrit :
Bonsoir, Je ne comprends pas trop le problème. En mettant les dépôts de stable, testing et unstable avec un pinning sur testing, tu vas passer progressivement de unstable à testing. Normalement sans douleur. Cordialement, JKB
Quelle serait la différence entre les 3 dépôts + pinning testing et simplement n'avoir que des références à testing ?
J'utilise testing en rolling-release. Je n'ai jamais réussi à faire avec la seule testing. J'ai donc les trois dépôts (ainsi que volatile et expérimental) dans mon source avec une préférence pour testing.
La peur que j'ai c'est qu'il me downgrade les paquets au lieu de simplement attendre que testing ait rattrapé ma version de sid (en gros sid au 20/08/2016).
Il ne le fera pas. Lorsque tu installes un soft avec apt-get -t unstable xxx, il reste dans l'état unstable jusqu'à ce que testing ait rattrapé unstable.
Car d'après la doc Debian, les scripts d'installation ne sont pas du tout prévu pour un downgrade des paquets.
C'est le moint que l'on puisse dire. Cordialement, JKB
Damien TOURDE a écrit :
Le lundi 22 août 2016 à 22:55 +0200, BERTRAND Joël a écrit :
Bonsoir,
Je ne comprends pas trop le problème. En mettant les dépôts de
stable,
testing et unstable avec un pinning sur testing, tu vas passer
progressivement de unstable à testing. Normalement sans douleur.
Cordialement,
JKB
Quelle serait la différence entre les 3 dépôts + pinning testing et
simplement n'avoir que des références à testing ?
J'utilise testing en rolling-release. Je n'ai jamais réussi à faire
avec la seule testing. J'ai donc les trois dépôts (ainsi que volatile et
expérimental) dans mon source avec une préférence pour testing.
La peur que j'ai c'est qu'il me downgrade les paquets au lieu de
simplement attendre que testing ait rattrapé ma version de sid (en gros
sid au 20/08/2016).
Il ne le fera pas. Lorsque tu installes un soft avec apt-get -t
unstable xxx, il reste dans l'état unstable jusqu'à ce que testing ait
rattrapé unstable.
Car d'après la doc Debian, les scripts d'installation ne sont pas du
tout prévu pour un downgrade des paquets.
Le lundi 22 août 2016 à 22:55 +0200, BERTRAND Joël a écrit :
Bonsoir, Je ne comprends pas trop le problème. En mettant les dépôts de stable, testing et unstable avec un pinning sur testing, tu vas passer progressivement de unstable à testing. Normalement sans douleur. Cordialement, JKB
Quelle serait la différence entre les 3 dépôts + pinning testing et simplement n'avoir que des références à testing ?
J'utilise testing en rolling-release. Je n'ai jamais réussi à faire avec la seule testing. J'ai donc les trois dépôts (ainsi que volatile et expérimental) dans mon source avec une préférence pour testing.
La peur que j'ai c'est qu'il me downgrade les paquets au lieu de simplement attendre que testing ait rattrapé ma version de sid (en gros sid au 20/08/2016).
Il ne le fera pas. Lorsque tu installes un soft avec apt-get -t unstable xxx, il reste dans l'état unstable jusqu'à ce que testing ait rattrapé unstable.
Car d'après la doc Debian, les scripts d'installation ne sont pas du tout prévu pour un downgrade des paquets.
C'est le moint que l'on puisse dire. Cordialement, JKB
didier gaumet
Le 23/08/2016 à 00:41, Damien TOURDE a écrit : [...]
La peur que j'ai c'est qu'il me downgrade les paquets au lieu de simplement attendre que testing ait rattrapé ma version de sid (en gros sid au 20/08/2016).
[...] Comme l'a dit Joël, ça n'arrivera pas, sauf si tu utilises apt-get (quand j'avais essayé je n'avais jamais réussi un downgrade avec aptitude) et que tu mets des priorités strictement supérieures à 1000 dans /etc/apt/preferences sur ce ce que tu veux downgrader, avant de revenir à des priorités normales par la suite
Le 23/08/2016 à 00:41, Damien TOURDE a écrit :
[...]
La peur que j'ai c'est qu'il me downgrade les paquets au lieu de
simplement attendre que testing ait rattrapé ma version de sid (en gros
sid au 20/08/2016).
[...]
Comme l'a dit Joël, ça n'arrivera pas, sauf si tu utilises apt-get
(quand j'avais essayé je n'avais jamais réussi un downgrade avec
aptitude) et que tu mets des priorités strictement supérieures à 1000
dans /etc/apt/preferences sur ce ce que tu veux downgrader, avant de
revenir à des priorités normales par la suite
Le 23/08/2016 à 00:41, Damien TOURDE a écrit : [...]
La peur que j'ai c'est qu'il me downgrade les paquets au lieu de simplement attendre que testing ait rattrapé ma version de sid (en gros sid au 20/08/2016).
[...] Comme l'a dit Joël, ça n'arrivera pas, sauf si tu utilises apt-get (quand j'avais essayé je n'avais jamais réussi un downgrade avec aptitude) et que tu mets des priorités strictement supérieures à 1000 dans /etc/apt/preferences sur ce ce que tu veux downgrader, avant de revenir à des priorités normales par la suite
Gabriel Philippe
2016-08-22 22:46 GMT+02:00 Damien TOURDE :
Je voulais savoir si en mettant mes sources.list en testing, et en ne faisant jamais au grand jamais de dist-upgrade, j'avais une change de repasser en "testing pur", sans perte ni fracas ?
Je voulais savoir si en mettant mes sources.list en testing, et en ne
faisant jamais au grand jamais de dist-upgrade, j'avais une change de
repasser en "testing pur", sans perte ni fracas ?
Je voulais savoir si en mettant mes sources.list en testing, et en ne faisant jamais au grand jamais de dist-upgrade, j'avais une change de repasser en "testing pur", sans perte ni fracas ?
Le mardi 23 août 2016 à 11:15 +0200, Gabriel Philippe a écrit :
Bref, testing c'est pour tester, pas pour utiliser.
Les bugs critiques de sécurité sont quand même corrigés assez rapidement mais pas prioritairement(stable est prioritaire et Sid bénéficie de son statut d'unstable avec des mises à jour au fur et à mesure). Pour les paquets bloqués dans une version ou dans un état non fonctionnel c'est vrai, et généralement soluble dans le pinning avec unstable en attendant que ça arrive dans Testing, en sachant que si ça n'arrive pas c'est à priori parce qu'il y a un problème d'intégration dans Testing (dépendances pas prêtes...) ou des bugs critiques rédhibitoires pour l'intégration. Testing et Unstable sont généralement utilisables... à ses risques et périls et à condition d'être un peu rôdé à la résolution des problèmes et à condition de savoir lire les avertissements au moment des mises à jour.
Le mardi 23 août 2016 à 11:15 +0200, Gabriel Philippe a écrit :
Bref, testing c'est pour tester, pas pour utiliser.
Les bugs critiques de sécurité sont quand même corrigés assez
rapidement mais pas prioritairement(stable est prioritaire et Sid
bénéficie de son statut d'unstable avec des mises à jour au fur et à
mesure).
Pour les paquets bloqués dans une version ou dans un état non
fonctionnel c'est vrai, et généralement soluble dans le pinning avec
unstable en attendant que ça arrive dans Testing, en sachant que si ça
n'arrive pas c'est à priori parce qu'il y a un problème d'intégration
dans Testing (dépendances pas prêtes...) ou des bugs critiques
rédhibitoires pour l'intégration.
Testing et Unstable sont généralement utilisables... à ses risques et
périls et à condition d'être un peu rôdé à la résolution des problèmes
et à condition de savoir lire les avertissements au moment des mises à
jour.
Le mardi 23 août 2016 à 11:15 +0200, Gabriel Philippe a écrit :
Bref, testing c'est pour tester, pas pour utiliser.
Les bugs critiques de sécurité sont quand même corrigés assez rapidement mais pas prioritairement(stable est prioritaire et Sid bénéficie de son statut d'unstable avec des mises à jour au fur et à mesure). Pour les paquets bloqués dans une version ou dans un état non fonctionnel c'est vrai, et généralement soluble dans le pinning avec unstable en attendant que ça arrive dans Testing, en sachant que si ça n'arrive pas c'est à priori parce qu'il y a un problème d'intégration dans Testing (dépendances pas prêtes...) ou des bugs critiques rédhibitoires pour l'intégration. Testing et Unstable sont généralement utilisables... à ses risques et périls et à condition d'être un peu rôdé à la résolution des problèmes et à condition de savoir lire les avertissements au moment des mises à jour.
Damien TOURDE
Le mardi 23 août 2016 à 11:06 +0200, Gabriel Philippe a écrit :
Et pourquoi testing? N'est-ce pas le pire des deux mondes? Cela n'a ni la stabilité de stable, ni la fréquence de mise à jour (et donc de corrections des problèmes) d'unstable. A une époque je l'utilisais, des bugs gênants apparaissaient parfois et restaient pendant des mois...
Testing c'est surtout pour pouvoir passer en stable quand la testing sera la nouvelle stable.
Il ne le fera pas. Lorsque tu installes un soft avec apt-get -t unstable xxx, il reste dans l'état unstable jusqu'à ce que testing ait rattrapé unstable.
Donc lors d'un apt-get update classique, il ne fera pas de downgrade si le pinning est bon, mais j'ai un doute sur celui qui serait bon. Si je fais un pinning prioritaire sur testing par exemple, ne va-t'il pas remplacer mes paquets par les paquets testing ? Car d'après mes souvenirs de la doc, le pinning est prioritaire sur le numéro de version...
Le mardi 23 août 2016 à 11:06 +0200, Gabriel Philippe a écrit :
Et pourquoi testing? N'est-ce pas le pire des deux mondes? Cela n'a
ni
la stabilité de stable, ni la fréquence de mise à jour (et donc de
corrections des problèmes) d'unstable. A une époque je l'utilisais,
des bugs gênants apparaissaient parfois et restaient pendant des
mois...
Testing c'est surtout pour pouvoir passer en stable quand la testing
sera la nouvelle stable.
Il ne le fera pas. Lorsque tu installes un soft avec apt-get -t
unstable xxx, il reste dans l'état unstable jusqu'à ce que testing
ait rattrapé unstable.
Donc lors d'un apt-get update classique, il ne fera pas de downgrade si
le pinning est bon, mais j'ai un doute sur celui qui serait bon.
Si je fais un pinning prioritaire sur testing par exemple, ne va-t'il
pas remplacer mes paquets par les paquets testing ?
Car d'après mes souvenirs de la doc, le pinning est prioritaire sur le
numéro de version...
Le mardi 23 août 2016 à 11:06 +0200, Gabriel Philippe a écrit :
Et pourquoi testing? N'est-ce pas le pire des deux mondes? Cela n'a ni la stabilité de stable, ni la fréquence de mise à jour (et donc de corrections des problèmes) d'unstable. A une époque je l'utilisais, des bugs gênants apparaissaient parfois et restaient pendant des mois...
Testing c'est surtout pour pouvoir passer en stable quand la testing sera la nouvelle stable.
Il ne le fera pas. Lorsque tu installes un soft avec apt-get -t unstable xxx, il reste dans l'état unstable jusqu'à ce que testing ait rattrapé unstable.
Donc lors d'un apt-get update classique, il ne fera pas de downgrade si le pinning est bon, mais j'ai un doute sur celui qui serait bon. Si je fais un pinning prioritaire sur testing par exemple, ne va-t'il pas remplacer mes paquets par les paquets testing ? Car d'après mes souvenirs de la doc, le pinning est prioritaire sur le numéro de version...
didier gaumet
Le 23/08/2016 à 18:03, Damien TOURDE a écrit : [...]
Si je fais un pinning prioritaire sur testing par exemple, ne va-t'il pas remplacer mes paquets par les paquets testing ? Car d'après mes souvenirs de la doc, le pinning est prioritaire sur le numéro de version...
non, pas de souci man apt_preferences: [...] Puis APT applique les règles suivantes pour déterminer la version du paquet qu'il faut installer (par ordre de priorité) : · Ne jamais revenir en arrière, sauf si la priorité d'une version disponible dépasse 1000. « Revenir en arrière » signifie installer une version moins récente que la version installée. Il faut noter qu'aucune des priorités par défaut n'excède 1000 ; de telles valeurs ne peuvent être définies que dans le fichier des préférences. Notez aussi qu'il est risqué de revenir en arrière. [...]
Le 23/08/2016 à 18:03, Damien TOURDE a écrit :
[...]
Si je fais un pinning prioritaire sur testing par exemple, ne va-t'il
pas remplacer mes paquets par les paquets testing ?
Car d'après mes souvenirs de la doc, le pinning est prioritaire sur le
numéro de version...
non, pas de souci
man apt_preferences:
[...]
Puis APT applique les règles suivantes pour déterminer la version du
paquet qu'il faut installer (par ordre de priorité) :
· Ne jamais revenir en arrière, sauf si la priorité d'une version
disponible dépasse 1000. « Revenir en arrière » signifie installer une
version moins récente que la version installée. Il faut noter qu'aucune
des priorités par défaut n'excède 1000 ; de telles valeurs ne peuvent
être définies que dans le fichier des préférences. Notez aussi qu'il est
risqué de revenir en arrière.
[...]
Le 23/08/2016 à 18:03, Damien TOURDE a écrit : [...]
Si je fais un pinning prioritaire sur testing par exemple, ne va-t'il pas remplacer mes paquets par les paquets testing ? Car d'après mes souvenirs de la doc, le pinning est prioritaire sur le numéro de version...
non, pas de souci man apt_preferences: [...] Puis APT applique les règles suivantes pour déterminer la version du paquet qu'il faut installer (par ordre de priorité) : · Ne jamais revenir en arrière, sauf si la priorité d'une version disponible dépasse 1000. « Revenir en arrière » signifie installer une version moins récente que la version installée. Il faut noter qu'aucune des priorités par défaut n'excède 1000 ; de telles valeurs ne peuvent être définies que dans le fichier des préférences. Notez aussi qu'il est risqué de revenir en arrière. [...]
Damien TOURDE
Merci pour le passage du man qui m'avait échappé. Je vais faire un pinning < 1000 pour testing et quand testing sera la nouvelle stable, y rester. Et puis si on ne me voit pas sur la liste, je serais peut-être en train de tout réinstaller en pleurant :^) Le mardi 23 août 2016 à 20:12 +0200, didier gaumet a écrit :
Le 23/08/2016 à 18:03, Damien TOURDE a écrit : [...]
Si je fais un pinning prioritaire sur testing par exemple, ne va- t'il pas remplacer mes paquets par les paquets testing ? Car d'après mes souvenirs de la doc, le pinning est prioritaire sur le numéro de version...
non, pas de souci man apt_preferences: [...] Puis APT applique les règles suivantes pour déterminer la version du paquet qu'il faut installer (par ordre de priorité) : · Ne jamais revenir en arrière, sauf si la priorité d'une version disponible dépasse 1000. « Revenir en arrière » signifie installer une version moins récente que la version installée. Il faut noter qu'aucune des priorités par défaut n'excède 1000 ; de telles valeurs ne peuvent être définies que dans le fichier des préférences. Notez aussi qu'il est risqué de revenir en arrière. [...]
Merci pour le passage du man qui m'avait échappé.
Je vais faire un pinning < 1000 pour testing et quand testing sera la
nouvelle stable, y rester.
Et puis si on ne me voit pas sur la liste, je serais peut-être en train
de tout réinstaller en pleurant :^)
Le mardi 23 août 2016 à 20:12 +0200, didier gaumet a écrit :
Le 23/08/2016 à 18:03, Damien TOURDE a écrit :
[...]
>
> Si je fais un pinning prioritaire sur testing par exemple, ne va-
> t'il
> pas remplacer mes paquets par les paquets testing ?
> Car d'après mes souvenirs de la doc, le pinning est prioritaire sur
> le
> numéro de version...
non, pas de souci
man apt_preferences:
[...]
Puis APT applique les règles suivantes pour déterminer la version du
paquet qu'il faut installer (par ordre de priorité) :
· Ne jamais revenir en arrière, sauf si la priorité d'une version
disponible dépasse 1000. « Revenir en arrière » signifie installer
une
version moins récente que la version installée. Il faut noter
qu'aucune
des priorités par défaut n'excède 1000 ; de telles valeurs ne peuvent
être définies que dans le fichier des préférences. Notez aussi qu'il
est
risqué de revenir en arrière.
[...]
Merci pour le passage du man qui m'avait échappé. Je vais faire un pinning < 1000 pour testing et quand testing sera la nouvelle stable, y rester. Et puis si on ne me voit pas sur la liste, je serais peut-être en train de tout réinstaller en pleurant :^) Le mardi 23 août 2016 à 20:12 +0200, didier gaumet a écrit :
Le 23/08/2016 à 18:03, Damien TOURDE a écrit : [...]
Si je fais un pinning prioritaire sur testing par exemple, ne va- t'il pas remplacer mes paquets par les paquets testing ? Car d'après mes souvenirs de la doc, le pinning est prioritaire sur le numéro de version...
non, pas de souci man apt_preferences: [...] Puis APT applique les règles suivantes pour déterminer la version du paquet qu'il faut installer (par ordre de priorité) : · Ne jamais revenir en arrière, sauf si la priorité d'une version disponible dépasse 1000. « Revenir en arrière » signifie installer une version moins récente que la version installée. Il faut noter qu'aucune des priorités par défaut n'excède 1000 ; de telles valeurs ne peuvent être définies que dans le fichier des préférences. Notez aussi qu'il est risqué de revenir en arrière. [...]
