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