Re: Inertie de Debian était : packages debian
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
Reply to: