Je voulais avoir des retours utilisateurs. J'utilise des distributions basées sur Ubuntu depuis quelques années et j'aimerais passer à une rolling release pour ne pas avoir à serrer les dents tous les 6 mois.
Je me suis donc installé une debian testing depuis 1 mois sur une VM avec Gnome Shell, j'en suis plus que satisfait :)
Maintenant, j'utilise linux tous les jours et j'aimerais savoir si il vous déjà arrivé d'avoir des problèmes avec les mises à jour.
Sinon, je voulais savoir : existe t-il quelque part l'historique des mises à jours proposées par debian testing ?
Autre question, comment cela se passe t-il lorsqu'on passe dans une période de freeze avant la sortie d'une nouvelle version stable ? Et ensuite, après la sortie, on reste automatiquement en testing ou on suit la stable et il faut rebasculer en testing ?
Merci pour vos retours !
Forum Linux.debian/ubuntu Utilisation de debian testing
9
juin
2016
# Daubian toasting
Posté par Marotte ⛧ . Évalué à 4.
Oui ça arrive
sans arrêt, surtout en testing ou unstable.Si tu veux du « rolling release » je te recommanderais plutôt unstable, justement à cause de cette période de freeze de testing… Testing est indiquée si on veut tester la prochaine version stable de Debian en avance, elle peut rester cassée par endroit plus longtemps que unstable, et notamment en période de freeze.
Ça dépend comment on configure, mais en général (c’est recommandé) on utilise le nom de code de la branche (et pas "testing" ou "stable"), donc quand il y a release et qu’on est en testing, on se retrouve en stable.
Il faut changer le nom de code pour passer à la testing (ou à la stable) suivante.
[^] # Re: Daubian toasting
Posté par Cyprien (site web personnel) . Évalué à 1.
Merci pour ta réponse, mais j'avoue ne pas tout comprendre. Si je lis bien cette page : https://www.debian.org/releases/index.fr.html, pour moi, unstable est moins stable que testing.
[^] # Re: Daubian toasting
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Les nouveautés arrivent dans unstable, puis, après dix jours, si aucun bug critique n'y a été détecté, dans testing.
La conséquence évidente, c'est qu'avec unstable, tu as les problèmes et les corrections en direct. Avec testing, tu évites les problèmes qui auront été détectés à temps — pendant les dix jours sus-mentionnés —, mais pas ceux qui ne l'auront pas été, pour lesquelles les corrections seront d'autant plus longues à arriver.
Personnellement, je recommanderais unstable si le but est vraiment de tester Debian pour contribuer à détecter les problèmes (il faut bien que quelqu'un le fasse !), et testing pour un usage quotidien averti (ce n'est pas une distribution stable !), en prenant au besoin des paquets précis d'unstable si ceux-ci apportent des corrections qui ne sont pas encore arrivées dans testing.
[^] # Re: Daubian toasting
Posté par Marotte ⛧ . Évalué à 2.
Je ne sais pas d’où tu sors ces 10 jours. Mais j’imagine que c’est une moyenne au doigt mouillé.
Ça fait des années que j’utilise Debian et il est évident que ce qui s’apparente le plus à une rolling release c’est unstable. Testing est une sorte de version béta de la prochaine stable (qui remplacera victorieusement son illustre prédécétrice) à destination de ceux qui testent sérieusement.
Mais je reconnais qu’utiliser sid quotidiennement c’est accepter quelques bugs de temps à autres…
[^] # Re: Daubian toasting
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6. Dernière modification le 10 juin 2016 à 15:40.
Pas du tout, ça vient de la Référence du Développeur Debian. Hors période de gel, les paquets envoyés dans unstable y restent un certain temps, qui dépend de la priorité définie par leur mainteneur pour cette mise à jour (10 jours pour un priorité faible, 5 pour une priorité moyenne, 2 pour une priorité élevée).
En ce qui me concerne, ça fait des années que je suis Développeur Debian, et si je suis loin de tout savoir à ce sujet, je suis à peu près au fait du fonctionnement des différentes version (en interne, on parle de distributions, à ne pas confondre avec différentes distributions GNU/Linux…).
Testing est techniquement une distribution à intégration continue différée, hors des périodes de gel. En période de gel, c'est figé en effet.
Unstable est une distribution à intégration continue immédiate, et elle est tout également concernée par le gel, de façon plus subtile : lorsque la testing est gelée, c'est toujours principalement la unstable qui sert recevoir les mises à jour, à ceci près qu'il ne s'agit plus de nouvelles versions mais seulement de corrections de bugs. Par conséquent, on évite d'envoyer de nouvelles versions dans unstable, qui ne seraient en aucun cas acceptées dans testing, et qui bloqueraient les envois de corrections pour des versions antérieures présentes dans testing.
Concrètement, supposons qu'en période de gel, testing contienne autojump 23-2. Arrive autojump version 24, et disons que je l'empaquette pour envoyer un autojump 24-1 dans unstable. On se retrouve alors avec, dans testing, autojump 23-2, et dans unstable, autojump 24-1. Là-dessus, quelqu'un découvre un bug critique sur autojump 23-2, et je prépare un paquet autojump 23-3 corrigeant cela. Problème, je ne peux pas l'envoyer dans unstable, qui contient autojump 24-1 qui est une version supérieure. Ce n'est pas dramatique, je dois alors l'envoyer dans testing-proposed-updates qui est faite pour cela, mais comme c'est un peu agaçant, en pratique on évite ce genre de cas, et, en période de gel, on évite d'envoyer des nouvelles versions dans unstable, préférant utiliser pour cela experimental.
Tout ça pour dire que si unstable est effectivement ce qui s'apparente le plus à une distribution à intégration continue, il ne faut pas non plus s'attendre à ce qu'elle soit toujours mise à jour au même rythme : en période de gel de la testing, son évolution sera également partiellement figée !
[^] # Re: Daubian toasting
Posté par Marotte ⛧ . Évalué à 2.
Merci pour toutes ces explications.
# Serre les dents
Posté par ʭ ☯ . Évalué à 4.
Travaillant sous Linux depuis 1998, je te propose mon expérience : après 6ans de Mandriva, j'ai passé 4 ans en Debian testing. Autant c'était agréable d'avoir des logiciels récents, autant il fallait savoir bidouiller un peu de temps en temps si on n'a pas bien lu la conséquence d'une mise à jour sur les centaines que j'ai passé. Bref, je me suis retrouvé une fois avec l'affichage graphique cassé.
Je suis du coup passé à Mageia pour la garantie de mises à jour testées, et jusqu'ici la promesse est tenue : j'ai notamment 2 ordis pour une association qui ont fait Mageia 1, 2, 3, 4 et maintenant 5, sans anicroches. Ceci étant, ce sont des postes de bureautique.
Bref, je ne te conseille pas testing pour être sans soucis. Je n'utilise pas Ubuntu, mais visiblement les mises à jours sont décevantes hors LTS? Si tu y vas, tu resteras en testing en permanence, et n'auras donc plus de mises à jours avec nouvelles version de logiciels pendant 6 mois, quand Debian est en freeze.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Serre les dents
Posté par Cyprien (site web personnel) . Évalué à 2.
Je te remercie pour ce retour !
# Debian unstable
Posté par nonas . Évalué à 3. Dernière modification le 09 juin 2016 à 16:01.
J'ai commencé il y a bien longtemps (2005 ?) par Gentoo puis j'en ai eu marre de tout compiler. Je suis alors passé chez Debian, et, comme toi, je me suis dirigé vers testing pour avoir des logiciels à jour mais sans avoir peur d'un système régulièrement complètement cassé (oui, unstable au début ça fait peur). Mais, ce n'est pas comme ça qu'il faut comprendre ces noms de code. Comme le rappelle Marotte au dessus : testing est faite pour tester la prochaine stable et les périodes de freeze sont très frustrantes (pas de mises à jour pendant plusieurs mois et parfois système cassé pendant assez longtemps). Donc tu seras obligé de serrer les fesses pendant les périodes de freeze.
J'en ai eu marre et suite à des avis ici même, je suis passé en unstable depuis 2 ans environ. Et là, on constate que si on fait un peu gaffe (apt-listbugs), on a presque aucun soucis ou alors c'est généralement réglé très vite (quelques jours grand maximum).
À l'opposé, sur le pc de ma copine, j'ai installé une debian stable avec certains backports (libreoffice et firefox en particulier) et je n'ai jamais eu de soucis insurmontables lors des montées de version.
[^] # Re: Debian unstable
Posté par Cyprien (site web personnel) . Évalué à 1.
Ok, je vais essayer de passer ma VM en unstable et tester pendant un mois et voir ce que ca donne. Merci pour ce conseil !
# Pour les utilisateurs qui s'y connaissent un minimum
Posté par Olivier (site web personnel) . Évalué à 3.
Depuis une dizaine d'années, je n'utilise que des Debian Testing sur toutes mes machines (usages perso, mais j'ai aussi différentes machines qui font serveurs).
J'apprécie le "rolling release" qui permet de faire évoluer l'OS par petites touches, et d'avoir des softs "assez" à jour.
De temps en temps, il y a un petit truc qui casse (il y a quelques jours, c'était "krunner"), mais c'est souvent corrigé quelques jours plus tard.
Lorsqu'une upgrade modifie un comportement d'un soft (nouvelle interprétation des fichiers de conf par exemple), c'est seulement le soft en question qui est planté, ce qui laisse le temps de le réparer. Alors que pour les distributions qui font des upgrades majeurs tous les 6 mois ou xx ans, on peut se retrouver à devoir réparer plusieurs softs en même temps après l'upgrade, ce qui est assez pénible.
Conclusion : Je préfère avoir des "petits problèmes" plus ou moins souvent, que de grosses galères tous les 6 mois.
En terme d'utilisation:
- j'ai un XFCE en plus de KDE sur ma machine principale. Si KDE est planté par des mises à jours, je peux continuer à travailler sur un desktop alternatif
- mon déport principal est en testing, mais il m'arrive de saupoudrer la machine de paquets "unstable" ou "experimentale", en utilisant le "Pinning" : http://jaqque.sbih.org/kplug/apt-pinning.html : La machine fonctionne en "testing", mais je peux lui forcer l'installation d'un paquet unstable ("aptitude install -t unstable firefox-esr" pour installer le Firefox d'Unstable). L'avantage, c'est que le gestionnaire de paquets ne téléchargera de unstable, que les paquets strictement nécessaires.
- lorsque le niveau de stabilité de ma machine principale est satisfaisant, je mets à jour mes autres machines.
Conclusion:
- "Testing" nécessite d'avoir un minimum de connaissances de Linux, et de ne pas avoir peur de fouiller dans les forums, ou de trouver soit-même une solution.
- Je trouve que c'est ce qui fait son charme, puisque cela permet de s'autoformer en réparant les trucs qui cassent. Tout en ayant un minimum de risque de tout casser (unstable & experimental).
- Un bémol cependant : Le volume des mises à jour. En mise à jour hebdomadaire, une Debian Testing c'est environ 200Mo chaque semaine. Et en mensuelle, il font compter 1Go par mois. Si tu as une connexion ADSL moyenne/faible (1Mb/s ou 128Ko/s), il vaut mieux évier , ou être patient…
[^] # Re: Pour les utilisateurs qui s'y connaissent un minimum
Posté par Cyprien (site web personnel) . Évalué à 1.
Merci pour ta réponse complète :)
Du coup, vu les réponses faites au dessus, pourquoi n'utilises tu pas unstable directement ?
[^] # Re: Pour les utilisateurs qui s'y connaissent un minimum
Posté par Olivier (site web personnel) . Évalué à 2.
Le facteur-risque est trop important par rapport à mes besoins :
- je ne suis pas contre avoir des softs à jours, mais pas au point d'attendre la toute dernière version
- si je dois attendre 10 jours pour que le paquet descende de unstable à testing, je peux faire avec.
L'autre critère important, pour moi, est que je gère les machines des membres de ma famille, d'amis, de collègues de boulot etc … Et la plus grand partie se fait par SSH. Afin d'assurer un support correct, il est plus facile pour moi de ne travaille que sur une seule version, donc j'ai mis tout le monde en Testing.
Donc dans ce cas-là, c'est pas mal si j'ai une version qui "stabilisée" pendant quelques jours, avant que je ne fasse des déploiement de mises à jours.
[^] # Re: Pour les utilisateurs qui s'y connaissent un minimum
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3. Dernière modification le 10 juin 2016 à 15:44.
Ce n'est pas vraiment ça non plus. Les mises à jour n'arrivent pas dans testing par paquets tous les dix jours, elles arrivent continument, avec dix jours (ou cinq, la plupart du temps, en fait) de retard par rapport à leur arrivée dans unstable. Ou plus pour les mises à jour boguées, qui n'entrent pas dans testing tant que ça n'a pas été corrigé, parce que tel est le bug de la distinction entre unstable et testing, bloquer les mise à jour qui introduisent des bogues critiques.
# As
Posté par benja . Évalué à 2. Dernière modification le 09 juin 2016 à 17:12.
a) historique
Il y a dans tous les cas /var/log/dpkg,log, Et puis en fonction de(s) l'interface(s) que tu as utilisée(s) tu auras aussi /var/log/aptitude.log, /var/log/apt/* (ou autres? pkg-kit, synaptic ont probablement aussi leur log qq part.). À partir d'un moment (une certaine taille p.e.) ces fichiers seront coupés et sauvegardés dans *.1.gz, puis 2.gz, jusqu'à 10 par défaut, par l'utlitaire logrotate.
b) freeze
Cf. c)
c) dans quelle version tu es un fois que la nouvelle stable sort.
Ça dépend. Soit dans ton fichier /etc/apt/sources.list tu as mis le nom de la version (stretch en l'occurence), ben alors tu passes en stable, le process de mise-à-jour ne modifie pas ce fichier (au contraire d'ubuntu où tu dois utiliser un outil spéficique pour faire un upgrade, dans debian tu peux simplement changer le nom de la distribution dans ce fichier (tu peux aussi sur ubuntu mais ça n'est pas "officiel", ymmv)). Soit tu as mis "testing", ben alors tu restes en testing et tu peux effectivement te poser la question de savoir s'il valait vraiment la peine de suivre le freeze ;-) Plus subtilement, tu peux passer en unstable pendant le freeze et repasser en testing juste au moment de la sortie car en gros un fois que la nouvelle stable est sortie, tous les paquets de unstable vont migrer dans testing. Enfin bon ça sera unstable pendant un moment (apt pinnning comme on t'as dit peut être un solution aussi pendant cette période de transition pour être dans un mix testing(freeze) + unstable)… donc bon à toi de voir.
(Bonne question btw!)
http://www.debian.org/releases/testing/index.fr.html
[^] # Re: As
Posté par Cyprien (site web personnel) . Évalué à 1.
Cool, merci pour ces réponses :)
# Point de vue d'un "Vieux"
Posté par Adphilech . Évalué à 2.
Bonjour à tous !
J'ai lu avec attention tous vos commentaires et sans vouloir aucunement polémiquer il me semble que vous oubliez une question fondamentale : Quelle utilisation vais je faire de mon ordinateur ?
En effet si votre machine est destiné au travail ou aux loisirs ou aux deux, ou à autre chose le problème n'est pas le même :
Je connais Debian depuis toujours via mon boulot (CNRS) l'utilise journellement depuis Etch et n'ai jamais eu de vrai problème: Je pense donc pouvoir vous dire que Debian est vraiment stable si vous utilisez Stable mais beaucoup moins si vous utiliser Sid (Je ne vous parlerai pas de testing, c'est pour moi un hybride sans intérêt (aïe,aïe,qu’est ce que je n'ai pas encore dit !)
Donc travail (et à fortiori serveurs) = Stable
Pour le fun (et la curiosité) = Unstable
Par ailleurs, je vous conseille FORTEMENT Sid si vous voulez apprendre : c'est en mettant les mains dans le cambouis que l'on apprend le mieux !
Heu, bon, maintenant, les cours de pépé, basta !
Bien que …
[^] # Re: Point de vue d'un "Vieux"
Posté par freem . Évalué à 3.
Très vrai.
Vrai aussi, la réputation de Debian n'est pas usurpée. Je me suis amusé avec ma machine personnelle, à plusieurs mois d'intervalle, de passer de stable à testing, de testing à unstable/experimental, en passant par des sessions de jeu sur
/etc/apt/preferencespuis à revenir à stable. Le retour à stable est une manipulation longue (résoudre les conflits à la main dans aptitude, c'est long et fastidieux) mais simple.J'ai aussi traîné mes octets sur la ml pendant un temps, et cette question revenais assez souvent (stable vs testing vs unstable).
En général, ce qui était conseillé pour les serveurs, c'était soit stable, soit unstable. Pas testing, parce que les correctifs de sécurité mettent (mettaient, je crois que ça a changé) trop de temps à descendre.
Pour le bureau…
Pas vraiment de consensus.
Mon avis est moi, c'est que pour ne pas être embêté, le mieux c'est stable + backports, avec éventuellement les dépôts source de testing/unstable enregistrés.
Comme ça, on peut avoir un système au cœur stable (Xorg, kernel, terminal), accompagné de logiciels «finaux» plus récents (browser, gestionnaire de fenêtres…).
Et si vraiment il faut à tout prix un truc dernier cri, alors on peu utiliser un paquet source plus récent et recompiler. Ça demande plus de travail, et ça ne se mets pas à jour tout seul, mais ça à le mérite d'éviter de casser le système.
Et si jamais un truc pète à cause d'une MàJ (sait-on jamais), par défaut, les anciens paquets sont conservés dans /var/cache/apt/archives.
Il suffit donc de purger le paquet incriminé (pas supprimer ni réinstaller: purger. Ça nettoie la config système au passage), puis d'aller installer à coup de dpkg la version voulue présente dans le répertoire sus-cité.
[^] # Re: Point de vue d'un "Vieux"
Posté par Michaël (site web personnel) . Évalué à 2.
Aptitude permet de sélectionner parmi les versions disponibles d'un paquet. Je ne me rappelle pas comment faire en revanche, mais c'est indiqué dans l'aide en ligne.
[^] # Re: Point de vue d'un "Vieux"
Posté par freem . Évalué à 3.
Exact, et c'est assez simple: il suffit d'aller dans la description du paquet, d'aller tout en bas et de prendre la version de son choix.
Sauf qu'en fait, il y à deux problèmes:
/etc/apt/sources.list(.d). Hors, quand tu fais une MàJ de stable vers stable (correctif de sécurité principalement) l'ancien paquet tombe dans l'oubli. Le seul moyen que je connaisse pour le récupérer, c'est le dossier que j'ai cité dans mon autre post. Et encore, problème: cette archive qu'aptitude construit, tu peux régler aptitude pour "supprimer automatiquement les paquets obsolètes" (ceux qui ne sont plus listés). Si tu fais ça, t'es bon pour aller faire de l'archéologie. Le fait de ne pas pouvoir indiquer combien de versions de backup conserver avec aptitude est l'un de ses inconvénients (mais c'est toujours mieux que les autres outils qui ne proposent même pas ce nettoyage automatique, sachant que quleques MàJ de gros paquets peuvent vite bouffer inutilement plusieurs Go).[^] # Re: Point de vue d'un "Vieux"
Posté par Adphilech . Évalué à 1.
Long et fastidieux, c'est certain, mais simple, je n'en suis pas très sûr, la seule fois que j'ai voulu faire ce rétropédalage je m'y suis sérieusement emm…heu…bêté : il faut dire que c'était à une période antédiluvienne ou tout se passait en ligne de commandes avec des instructions aussi alambiquées que hasardeuses …
Vous faites bien d'utiliser "purge" car on se retrouve parfois avec un nombre impressionnant de fichiers ne servant plus à rien. Pour visualiser tous ces fichiers orphelins je vous conseille aussi de temps en temps un petit coup de :
aptitude search ~c
suivi d'un :
aptitude purge ~c
(mais jamais sans vous être assuré que vous n'avez pas gardé volontairement un vieux fichier obsolète que vous vouliez reprendre pour le remanier, …je sais de quoi je parle! Étourdi!)
[^] # Re: Point de vue d'un "Vieux"
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Le retour en arrière, ça peut marcher, mais ce n'est pas du tout prévu. C'est un peu logique en même temps : si à chaque nouvelle version d'un paquet on veille à ce que tout soit bien migré depuis les versions précédentes, dans chaque version on n'a pas du tout veillé à ce que tout soit bien migré depuis une version future, c'est impossible !
[^] # Re: Point de vue d'un "Vieux"
Posté par freem . Évalué à 2.
Mon secret: l'utilisation d'une interface interactive nommée aptitude. Bien qu'il soit foutrement lent à faire le moindre truc (je suis manifestement relativement jeune, et donc impatient :)) quand une cassure est détectée, les choses restent simples à condition d'avoir aux paquets auxquels ont veut revenir.
Bon, j'imagine qu'avoir des notions de quels paquets servent à quoi aide, mais c'est en général assez explicite.
Le pire étant que la purge ne résout pas tout: certains fichiers ou répertoires sont générés par le logiciel, et non par le script d'installation, et ne seront donc pas nettoyés par une purge.
Mais les mainteneurs de Debian sont assez sérieux de ce côté là.
Dans ces cas la, je préfère faire une copie en .bak, ça évite les ennuis :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.