Re: revenir en testing ?
On Thu, Aug 01, 2002 at 09:46:41 +0200, Lionel Elie Mamane wrote:
> Package: *
> Pin: release a=testing
> Pin-Priority: 900
>
> Package: *
> Pin: release a=unstable
> Pin-Priority: 50
Si j'ai bien compris, avec 50, on reste avec la version unstable
actuellement installée jusqu'à ce qu'il y ait une version testing
ultérieure, puisque 50 < 100 (100 étant la priorité de la version
installée). Si on met par exemple 500 à la place de 50, alors les
upgrades se font un unstable jusqu'à ce qu'il y ait une version
testing ultérieure qui apparaît, auquel cas le package restera en
version testing par la suite. C'est ça?
Maintenant, le problème de la première solution est qu'on reste
facilement bloqué sur la version actuellement installée, et s'il
y a des bugs importants corrigés par une version unstable (sans
qu'il y ait de testing), il n'y aura pas d'upgrade. Plutôt gênant!
Alors est-ce que la seconde solution marche bien en pratique? Par
exemple, est-ce qu'on peut avoir quelque chose du genre pour un
package donné:
_ Version installée: 1.0 (unstable).
_ La version 1.1 apparaît en unstable -> upgrade en 1.1.
_ La version 1.2 apparaît en unstable -> upgrade en 1.2.
_ La version 1.1 apparaît ensuite en testing.
Mais comme la 1.1 est apparue plus tard en testing, il n'y a pas
d'upgrade et l'installation reste en unstable. Ou alors est-ce
qu'une même version apparaît à la même date en testing et en
unstable (éventuellement à une date ultérieure en testing s'il
n'y a pas de nouvelle version en unstable pendant ce temps)?
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Reply to: