Fran�ois Boisson a �crit :
Hmm, c'est Vendredi.
...
Une solution pourrait �tre de vaguement officialiser cela en cr�ant un
d�pot de paquet r�cent (bof) ou bien en s'arrangeant pour que les paquets
sources de testing voire sid puissent syst�matiquement �tre recompil�s sur
la woody. L'impossibilit� quasi syst�matique de recompiler un paquet sid
sur une woody me parait le probl�me le plus g�nant et il est souvent plus
simple de se refaire un paquet � partir des sources que d'adapter les
paquets sid � la stable. Le probl�me est que cela fige un peu les
utilitaires de construction des paquets.
Si tu veux backporter un paquet, il faut t'attendre � le faire pour
plusieurs : soit parceque les dependances ne sont pas a jour soit
parceque les paquets n'existent pas.
Pour faciliter la chose, il faudrait moins de diff�rences entre 2
releases donc un processus de stabilisation plus court.
3) Une machine de production (typiquement salle de cours). L�, la
stabilit� est la plus importante l'installation doit surtout �tre
reproductible.
J'ai resolu le pb gr�ce fai
4) Le serveur. Personnellement, la stable me parait indispensable, mais
des besoins parfois importants peuvent �tre n�c�ssaires (typiquement
spassassin). La testing est une erreur car il n'y a pas de mis � jour de
s�curit� sur la testing je crois. La possibilit� de recompiler
ponctuellement facilement un paquet est ou plut�t serait int�ressante.
Pour ma part, j'utilise sarge sur les serveurs. Bien evidemment, si je
pouvais utiliser woody, je le ferais mais elle est vraiment trop d�pass�e.
En revanche, je g�re moi-m�me les paquets sensibles (kernel, iptables,
samba, ...)
Pour ce qui est des probl�mes de s�curit�, ils sont g�n�ralement suivi
d'une nouvelle version des sources donc d'un nouveau paquet. Et si je
juge le risque trop grand alors je repaquette.
Fran�ois Boisson
