Euh, personne ne recommande d'utiliser Debian/Unstable. Si tu l'utilises, alors tu dois accepter que ta Debian peut très bien se retrouver fusillée d'un coup, et ne plus démarrer. Bon ok, c'est extrème, mais bon.
Experimental n'est "activement" utilisé que depuis quelques mois. Avant c'était juste pour y poser la toute dernière version d'un paquet juste en test de création avant de l'intégrer à Unstable. De plus, ce repository a quelques défauts. Notamment, pas d'auto-build pour les xx architectures...
Mais la chose qui m'étonne, c'est que tu ne parles pas de Testing. Pour un desktop, c'est la solution priviligiée. Certes, les tous derniers logiciels - dans leur version super top qu'elle vient de sortir dans la nuit et que je sais pas si elle marche - n'y sont pas disponibles, mais ils y sont rapidement. Seulement elle est régulièrement à jour, et le but actuel est de ne plus casser Unstable pendant des mois (comme c'est arrivée fréquemment avec l'introduction de glibc ou gcc archi buggués sur autre chose que x86 ou ppc), ce qui a pour conséquence de complètement bloquer Testing. Donc Testing est la solution (pour le moment). Certes de temps en temps, ça peut légèrement casser, certes il y a des bugs (je les cherche encore perso), et très rarement il y a un petit conflit de paquet qu'il était caché dans son coin (une fois par an je vois ça), et encore ça se corrige facilement.
Stable, bon ok, c'est bien quand ça sort, mais au bout d'un an elle devient effectivement presque obsolète. Néanmoins elle est et reste stable / sécurisée (à condition de se mettre à jour sur security.debian.org bien entendu). De plus, elle bénéficie de pas mal de backports. Donc, ça reste une solution viable, surtout pour un serveur. Et si on est un vrai admin, on est capable de « backporter » sois-même les paquets pour Stable. On peut même penser à monter une équipe qui s'occuperait de ça, et pourrait même générer un repository consacré (sur certains composants, tels les FTP, Apache et consors).
Nota: je suis tout à fait d'accord pour dire que Debian devrait faire évoluer sa politique. Le cycle actuel est bien trop long, et pas très pratique. Il est par exemple très dur de faire entrer tout un composant. Par exemple, GNOME, KDE, et ces genres de choses. Mais pour le moment, j'avoue que j'en suis assez content. Certes on met un moment avoir la nouvelle version de Gnome, ou ce genre de choses. Dans ce cas, ben on peut tenter le feu et essayer les paquets d'experimental, ou si on veut être plus prudent : des paquets provenants de Unstable. Je le fais régulièrement, sur des paquets non essentiels (liferea, galeon, gimp, et ce genre de logiciels).
On peut aussi tourner légèrement la tête, et on voit quelque chose de très intéressant : Progeny ( http://progeny.com/(...) ). Son idée de développement composants par composants (components) est vraiment très intelligente. Chaque chose est développée à part et en corrélation avec les autres composants. Pour moi c'est vers cette idée que devrait se tourner Debian, si elle veut évoluer.
Et puis, pour un développement plus efficace des paquets, experimental devrait pouvoir être auto-build.
Aller, pour ceux qui cherchent des paquets backportés (ou non existants dans Debian) : http://apt-get.org/(...)
# Euh....
Posté par Julien Portalier . En réponse au journal Debian et sa politique de mise à jour.. Évalué à 9.
Experimental n'est "activement" utilisé que depuis quelques mois. Avant c'était juste pour y poser la toute dernière version d'un paquet juste en test de création avant de l'intégrer à Unstable. De plus, ce repository a quelques défauts. Notamment, pas d'auto-build pour les xx architectures...
Mais la chose qui m'étonne, c'est que tu ne parles pas de Testing. Pour un desktop, c'est la solution priviligiée. Certes, les tous derniers logiciels - dans leur version super top qu'elle vient de sortir dans la nuit et que je sais pas si elle marche - n'y sont pas disponibles, mais ils y sont rapidement. Seulement elle est régulièrement à jour, et le but actuel est de ne plus casser Unstable pendant des mois (comme c'est arrivée fréquemment avec l'introduction de glibc ou gcc archi buggués sur autre chose que x86 ou ppc), ce qui a pour conséquence de complètement bloquer Testing. Donc Testing est la solution (pour le moment). Certes de temps en temps, ça peut légèrement casser, certes il y a des bugs (je les cherche encore perso), et très rarement il y a un petit conflit de paquet qu'il était caché dans son coin (une fois par an je vois ça), et encore ça se corrige facilement.
Stable, bon ok, c'est bien quand ça sort, mais au bout d'un an elle devient effectivement presque obsolète. Néanmoins elle est et reste stable / sécurisée (à condition de se mettre à jour sur security.debian.org bien entendu). De plus, elle bénéficie de pas mal de backports. Donc, ça reste une solution viable, surtout pour un serveur. Et si on est un vrai admin, on est capable de « backporter » sois-même les paquets pour Stable. On peut même penser à monter une équipe qui s'occuperait de ça, et pourrait même générer un repository consacré (sur certains composants, tels les FTP, Apache et consors).
Nota: je suis tout à fait d'accord pour dire que Debian devrait faire évoluer sa politique. Le cycle actuel est bien trop long, et pas très pratique. Il est par exemple très dur de faire entrer tout un composant. Par exemple, GNOME, KDE, et ces genres de choses. Mais pour le moment, j'avoue que j'en suis assez content. Certes on met un moment avoir la nouvelle version de Gnome, ou ce genre de choses. Dans ce cas, ben on peut tenter le feu et essayer les paquets d'experimental, ou si on veut être plus prudent : des paquets provenants de Unstable. Je le fais régulièrement, sur des paquets non essentiels (liferea, galeon, gimp, et ce genre de logiciels).
On peut aussi tourner légèrement la tête, et on voit quelque chose de très intéressant : Progeny ( http://progeny.com/(...) ). Son idée de développement composants par composants (components) est vraiment très intelligente. Chaque chose est développée à part et en corrélation avec les autres composants. Pour moi c'est vers cette idée que devrait se tourner Debian, si elle veut évoluer.
Et puis, pour un développement plus efficace des paquets, experimental devrait pouvoir être auto-build.
Aller, pour ceux qui cherchent des paquets backportés (ou non existants dans Debian) : http://apt-get.org/(...)