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 <[EMAIL PROTECTED]> - 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
