La réponse en plus détaillée: Stable est une version figée, qui s'efforce au maximum de ne pas bouger, et ce jusqu'à la prochaine sortie de la version Stable (c'est-à-dire lorsque Etch deviendra la nouvelle Stable, et que Sarge passera en OldStable). La Stable ne change que par deux moyens: les mises à jour de sécurité, et les backports. Dans les deux cas, la distribution est aussi peu changée que possible, sans toucher aux dépendances du logiciel, sauf s'il n'y a vraiment pas moyen de faire autrement.
En prenant des paquets venant de Testing et/ou Unstable, d'autres paquets ont été "récupérés" de ces distributions, principalement des bibliothèques (libXYZ). Les versions de Testing et d'Unstable sont très, très rarement les mêmes que celles de la Stable, et des versions différentes d'un même paquet peuvent ainsi se retrouver sur le même système. Unstable et Testing ont également des paquets supplémentaires par rapport à Stable, d'ailleurs.
Dans le cas présent, ksplash-engine-moodin semble (d'après packages.debian.org) n'être disponible que pour Unstable. Ses prérequis semblent se référer à des paquets plus récents que la Stable, au moins libidn11 qui donne deux versions différentes. Il faudrait donc faire un peu de magie avec Apt pour règler ce conflit et forcer l'installation de ksplash.
Je ne peux pas recommander de mélanger les distributions, car elles forment un tout relativement cohérent, surtout la Stable bien évidemment, mais même Unstable (une fois que les plâtres sont essuyés). Si seulement quelques paquets non disponibles dans la Stable sont nécessaires, ma préférence va à la compilation à la main des programmes, afin qu'ils ne chamboulent pas Apt. Les backports sont également une solution relativement peu risquée, à supposer que le logiciel demandé y soit bien présent.
Si de telles méthodes ponctuelles ne suffisent pas, passer complètement à Unstable (voire Testing, mais celle-ci peut rencontrer des problèmes longs à résoudre au niveau de l'existence et des dépendances des paquets) me parait être préférable. Même en Unstable, les mises à jour régulières ne sont pas une obligation, et Unstable permet de profiter des nouveaux paquets directement.
Bref, il me semble y avoir trois voies distinctes:
- Les backports ou la compilation, en ne touchant pas au reste du système (tout en Stable).
- Tout passer en Unstable avec mises à jour plus ou moins régulières selon les besoins, pour un système plus cohérent.
- Un peu de sorcellerie avec Apt et la sorcellerie, où la difficulté semble être de faire cohabiter des versions différentes du même paquet (toutes les deux requises par d'autres paquets).
[^] # Re: Conflits de version?
Posté par Alneyan . En réponse au message pb dépendances APT. Évalué à 2.
La réponse en plus détaillée: Stable est une version figée, qui s'efforce au maximum de ne pas bouger, et ce jusqu'à la prochaine sortie de la version Stable (c'est-à-dire lorsque Etch deviendra la nouvelle Stable, et que Sarge passera en OldStable). La Stable ne change que par deux moyens: les mises à jour de sécurité, et les backports. Dans les deux cas, la distribution est aussi peu changée que possible, sans toucher aux dépendances du logiciel, sauf s'il n'y a vraiment pas moyen de faire autrement.
En prenant des paquets venant de Testing et/ou Unstable, d'autres paquets ont été "récupérés" de ces distributions, principalement des bibliothèques (libXYZ). Les versions de Testing et d'Unstable sont très, très rarement les mêmes que celles de la Stable, et des versions différentes d'un même paquet peuvent ainsi se retrouver sur le même système. Unstable et Testing ont également des paquets supplémentaires par rapport à Stable, d'ailleurs.
Dans le cas présent, ksplash-engine-moodin semble (d'après packages.debian.org) n'être disponible que pour Unstable. Ses prérequis semblent se référer à des paquets plus récents que la Stable, au moins libidn11 qui donne deux versions différentes. Il faudrait donc faire un peu de magie avec Apt pour règler ce conflit et forcer l'installation de ksplash.
Je ne peux pas recommander de mélanger les distributions, car elles forment un tout relativement cohérent, surtout la Stable bien évidemment, mais même Unstable (une fois que les plâtres sont essuyés). Si seulement quelques paquets non disponibles dans la Stable sont nécessaires, ma préférence va à la compilation à la main des programmes, afin qu'ils ne chamboulent pas Apt. Les backports sont également une solution relativement peu risquée, à supposer que le logiciel demandé y soit bien présent.
Si de telles méthodes ponctuelles ne suffisent pas, passer complètement à Unstable (voire Testing, mais celle-ci peut rencontrer des problèmes longs à résoudre au niveau de l'existence et des dépendances des paquets) me parait être préférable. Même en Unstable, les mises à jour régulières ne sont pas une obligation, et Unstable permet de profiter des nouveaux paquets directement.
Bref, il me semble y avoir trois voies distinctes:
- Les backports ou la compilation, en ne touchant pas au reste du système (tout en Stable).
- Tout passer en Unstable avec mises à jour plus ou moins régulières selon les besoins, pour un système plus cohérent.
- Un peu de sorcellerie avec Apt et la sorcellerie, où la difficulté semble être de faire cohabiter des versions différentes du même paquet (toutes les deux requises par d'autres paquets).