Hmm, c'est Vendredi. En fait tout d�pend de l'utilisation de la machine et de la situation
1) La situation d'un particulier ne cherchant pas forcement une stabilit� en b�ton est assez simple: Si il veut s'amuser et s'int�resse aux derniers d�veloppement, sid ou experimental. Sinon, sarge (testing) est parfait. 2) Le particulier qui veut une machine en b�ton utilisera la woody pour cela mais cherchera ponctuellement des paquets r�cents pour des besoins tr�s pr�cis. La seule solution actuelle est celle des backports dont le succ�s est quand m�me une �pine dans le pied du syst�me Debian cqr il souligne le probl�me essentiel. 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. 3) Une machine de production (typiquement salle de cours). L�, la stabilit� est la plus importante l'installation doit surtout �tre reproductible. La stable est pr�cieuse dans ce cas (sans surprise), seul quels paquets dus � des besoins locaux sont peut �tre n�c�ssaire. 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. Le plus l�s� dans la situation actuelle est le particulier qui veut � la fois une machine stable ET les logiciels dernier cri. La r�ponse goto Mdk est adapt�e mais brutale peut �tre, je pense qu'avoir une compatibilit� minimale entre les diff�rentes versions de debhelper (le fameux dh_compat) me parait la meilleure r�ponse (exemple: pourquoi diable renommer dh_installmanpages en dh_installman, pourquoi modifier le comportement de dh_install (certains fichiers ne sont (seraient plut�t, je n'ai pas bien compris lorsque �a m'est arriv�) plus install�s au m�me endroit), etc). Fran�ois Boisson
