Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
nous sommes tous différents ... c'est notre point commun ...
Association Debian-Facile - Les cahiers du débutant - ISO Debian-Facile - 3hg - nakeDeb
GNU/Linux©2006-2024
Hors ligne
Hors ligne
Bonjour,
j'ai toujours vu des commentaires assez désobligeants sur testing, et le lien de arpinux va dans ce sens.
On peut se poser la question : si testing n'est bonne nulle part et pour personne, pourquoi la mettre à disposition ???
Je dirai pour "tester" en grandeur nature non ?
Je pense que les personnes qui s'occupent des différentes version système ne peuvent pas prévoir "tout" les cas de figure à tester.
La meilleur solution : la rendre disponible pour que tu es des personnes qui l'éprouvent au quotidien.
Du coup, il me semble que la dénomination test permet d'alerter les gens "attention, ça marche mais.... ça peut péter entre tes mains : ton retour d'expérience nous intéresse pour améliorer le système".
Dernière modification par pytolux (29-01-2021 22:36:59)
Hors ligne
On peut se poser la question : si testing n'est bonne nulle part et pour personne, pourquoi la mettre à disposition ???
Le lien d'Arpinux y répondais
À quoi sert Debian testing ?
Elle sert à développer la prochaine Debian stable.
C'est pour les contributeurs de Debian qui font des retours de bugs pour que la future stable sorte stable !
Dernière modification par otyugh (29-01-2021 22:48:27)
Hors ligne
j'ai toujours vu des commentaires assez désobligeants sur testing, et le lien de arpinux va dans ce sens.
On peut se poser la question : si testing n'est bonne nulle part et pour personne, pourquoi la mettre à disposition ???
L’article lié par arpinux répond à cette question, dans la section « Mais alors, pourquoi Debian testing existe-t-elle ? ».
Ce n’est absolument pas désobligeant d’ailleurs de rappeler à quoi sert vraiment testing, surtout quand à côté autant de personnes n’ayant pas compris son rôle continuent à la conseiller comme une distribution à utiliser au quotidien.
Hors ligne
De retour sur la communauté car après avoir essayé plusieurs distributions je voudrais remettre Debian sur mon Thinkpad x230
L'architecture matérielle de ta machine est sortie il y a maintenant plusieurs années.
La Debian Buster Stable devrait bien la prendre en charge.
La Debian Stable est une distribution linux dite semi-conservatrice.
Elle est dans la moyenne en terme de version de logiciels, se positionnant entre une Ubuntu, au top, et une Redhat plutôt arriérée.
Des versions de logiciels plus anciens permettent d'avoir une meilleure stabilité.
Une Debian Testing, c'est plus proche d'une Ubuntu. Ça reste quand même expérimental.
Tu as besoin d'utiliser des versions de logiciels plus récents ? Autant installer une Ubuntu.
Tu veux participer au développement de la future Debian ? Installe donc la Debian Testing.
Hors ligne
Le lien d'Arpinux y répondais
Oui, mais alors désolé, quand tu vois le résumé tout en finesse et en nuances, t'as pas envie d'aller plus bas !
On dirait un media mainstream qui parle d'hydroxychloroquine 
Ce que je ne comprends pas bien, c'est :
- pourquoi testing est souvent présentée comme moins stable que Sid ?
- la stratégie des backports/PPA m'a toujours paru être un pis aller : tu installes une stable et tu mets dedans tout un tas de paquets pas prévus pour fonctionner avec ni testés dans ce sens. J'ai du mal à comprendre que c'est mieux que testing qui malgré sa jeunesse reste homogène, les paquets sont testés ensembles
L'architecture matérielle de ta machine est sortie il y a maintenant plusieurs années.
La Debian Buster Stable devrait bien la prendre en charge.
Pas sûr... J'ai une machine de 2012 qui justement n'était prise en charge ni par Buster (pb de wifi, mise en veille, jauge d'énergie, son, rien que ça...) ni par la Debian 9 (wifi), et qui a marché instantanément sous testing juste après le passage en stable de Buster
Pour ce qui est d'Ubuntu, mon expérience limitée m'a fait constater que j'avais beaucoup plus de soucis avec Ubuntu (y compris des versions LTS) qu'avec Debian testing.
Après, ce n'est qu'une petite expérience avec 2 ou 3 machines, mais quand tu as systématiquement des embrouilles avec les mises à jour d'Ubuntu et strictement aucun pb avec celles de Debian testing, ton choix est fait 
Hors ligne
la stratégie des backports/PPA m'a toujours paru être un pis aller
qui a parlé de PPA? stratégie PPA sur Debian y'a pas
Tout tes dit dans le lien d'arpinux, le texte est clair et précis
pas long le texte faut pas abusé, on s'excuse pour les doubles interligne alors
comme dirait Gaston
m'enfin 
Dernière modification par Croutons (31-01-2021 12:37:46)
-->les cahiers du debutant<-- WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde
En ligne
Acer Aspire 5733 - Debian 12 Xfce
Hors ligne
et la version live-build de stable bug avec l'UEFI ... j'ai donc du me rabattre sur la version testing, seule version compatible proprement avec mes sources nakedeb actuelle
nous sommes tous différents ... c'est notre point commun ...
Association Debian-Facile - Les cahiers du débutant - ISO Debian-Facile - 3hg - nakeDeb
GNU/Linux©2006-2024
Hors ligne
comme quoi... bah ... ça dépend !
bah oui, devant la complexité de la chose, faut rester humble. Herve33 ne dit rien d'autre.
Il ne faut pas se méprendre : je ne donne pas une RECOMMANDATION, je fournis un TÉMOIGNAGE de mon expérience, après, chacun en fait ce qu'il veut !
testing est, comme son nom l'indique, hors de la garantie de stabilité de debian. c'est donc, navré de le dire, chercher un peu la merde d'aller piocher dedans.
ben j'ai eu du pot (pourtant, c'est normalement quand on marche dedans qu'on a du pot, non )
qui a parlé de PPA? stratégie PPA sur Debian y'a pas
Beta-Pictoris a parlé d'Ubuntu, et tu sais sans doute mieux que moi que PPA sur Ubuntu est le pendant de back port sur Debian
Tout tes dit dans le lien d'arpinux, le texte est clair et précis
je te renvoie la balle, faut lire ce que j'ai écrit : oui, le lien était clair dès le début, trop clair même, c'est ce que je lui reproche. Et j'ai regardé jusqu'au bout, désolé, je reste sur ma faim sur la raison pour laquelle sid est plus stable que testing
Et après, honnêtement, je m'en fous ! Ma testing marche bien, j'y reste.
Mais si un béotien passe par là et qu'il veut une raison autre qu'une affirmation, désolé, il reste sur sa faim aussi
Hors ligne
ben j'ai eu du pot
Sans doute ça doit dépendre aussi des logiciels installés, plus y en a plus tu testes
> Débuter sur Debian
Principales commandes Linux+ISOs DF+Les cahiers du débutant
> Débuter sur openSUSE
Site officiel + Wiki fr + Forum fr +Guide du débutant sur Leap 15.x
Hors ligne
Oui, mais alors désolé, quand tu vois le résumé tout en finesse et en nuances, t'as pas envie d'aller plus bas !
Et encore, la première version que j'avais écrite pour cet article était un exemple d'absence totale de nuance — https://debian-facile.org/doc:faq:pourq … 1609981400
C'est captnfab qui est passé dessus ensuite pour en faire un article un peu plus détaillé et pédagogique, merci à lui
Hors ligne
ça doit dépendre aussi des logiciels installés, plus y en a plus tu testes
En fait, je reste sobre, et quasiment tout ce que j'ai est dans les dépôts de base, free et non free, donc peu de risques en fait
Et encore, la première version que j'avais écrite pour cet article était un exemple d'absence totale de nuance
Faudrait que je me familiarise avec Reportbug histoire d'être un peu utile, mais c'est vrai que quand tu ne fais pas de développement, c'est bien austère voire ésotérique tout ça...
Hors ligne
1. Il doit avoir été dans la distribution instable pendant 10, 5 ou 2 jours, en fonction de l'urgence de la mise en ligne ;
2. Il devra être compilé et à jour sur toutes les architectures sur lesquelles il a été compilé par le passé dans la distribution instable ;
3. Il ne doit pas avoir de rapport de bogue entrant dans la catégorie critique pour la parution dans la prochaine distribution qui ne concerne pas déjà la version actuellement dans la "distribution de test" (regardez ci-dessous pour plus d'informations) ;
4. Toutes ces dépendances doivent soit être satisfaites par les paquets d'ores et déjà présents dans la distribution de test, ou bien être satisfaites par un ensemble de paquets qui sont installés au même instant ;
5. L'opération d'installation des paquets dans la distribution de test ne doit pas casser un seul paquet actuellement dans cette distribution (regardez ci-dessous pour plus d'informations) ;
Ok, pas tellement plus vieux que les paquet sid, à priori testé plus longtemps, avec des critères de qualité plus élevés.
-----------------------------------
Moi, j'y vois déjà un atout intéressant (1):
« Testing » est mise à jour plus souvent que « stable », mais moins que « unstable »,
Peut être que le texte en anglais est un poil plus orienté (1).
Testing changes more often than stable, but not as crazily as unstable,
Moins de mises à jour, qui ne sont pas forcément intéressantes, je suis pas à 10 jours prêts pour avoir une nouvelle fonctionnalité.
-----------------------------------
Ensuite, si ça bug, ou si, (je ne retrouve plus au j'avais lu ça) un paquet est soit absent / retiré / rétrogradé de testing, il peut alors être pertinent de faire un peu de pinning sid.
La phrase suivante semble aller dans ce sens (1)
C'est une bonne idée d'inclure unstable et experimental dans vos sources apt afin d'avoir accès à des paquets plus récents si nécessaire.
Le pinning sid peut être utile en ce qui concerne les mise à jour de sécurité également (1):
C'est une bonne idée d'installer les mises à jour de sécurité d'unstable car elles prennent plus de temps pour atteindre testing et l'équipe en charge de la sécurité ne publie que des mises à jour vers unstable
-----------------------------------
Concernant les considérations sur stabilité on trouve (2):
Testing a des logiciels plus à jour que Stable et est cassée moins souvent que unstable. Mais lorsque cela arrive, la correction met du temps à être appliquée. Des fois il peut s'agir de plusieurs jours et dans certains cas plusieurs mois. Testing n'a par ailleurs pas de prise en charge permanente de la sécurité.
Unstable a les logiciels les plus récents et change beaucoup. Par conséquent, elle peut être cassée à n'importe quel moment. Cependant, les problèmes sont souvent corrigés en quelques jours et cette distribution offre toujours les dernières versions des logiciels empaquetés pour Debian.
Au moment de décider entre testing et unstable, gardez à l'esprit qu'il est par moment préférable de suivre testing plutôt qu'unstable. Un des auteurs de ce document a rencontré ce cas lors de la transition de gcc3 à gcc4. Le paquet labplot était impossible à installer sur une machine unstable car certaines de ses dépendances avaient passé la transition gcc4 et d'autres pas. Au même moment, le paquet de testing était installable sur une machine testing puisque les paquets ayant effectué la transition gcc4 n'avaient pas atteint testing.
Je résumerai ainsi:
- casse moins souvent mais plus longtemps => maintenance moins contraignante, ajout pinning sid (quand) necessaire
- màj sécurité plus tardives => pinning sid
-----------------------------------
De mon point de vue, c'est que franchement, la différence est assez mince, et pour qui sait faire un poil de ligne commande et est assez patient pour lire les messages d'avertissement quand il y en a un, sid/testing : c'est stable .
Utiliser testing permet une maintenance moins soutenue (moins de màj, moins de bugs) au prix d'une installation un peu plus complexe avec la mise en place d'un pinning sid/experimental adéquate.
Et testing plus instable que sid? Franchement, rien ne va en ce sens, plutôt le contraire, de part du principe même de construction de testing. Le reste n'est que mauvaises expériences et considérations personnelles (même les citations de la doc semblent inférer une généralité à partir d'un exemple unique).
Bien à vous,
un utilisateur non biaisé de testing
(1) https://wiki.debian.org/fr/DebianTesting
(2) https://www.debian.org/doc/manuals/debi … .html#s3.1
Dernière modification par David5647 (01-02-2021 11:58:19)
Hors ligne
Testing a des logiciels plus à jour que Stable et est cassée moins souvent que unstable.
Le souci ici est que cette phrase, bien qu'issue de la documentation officielle de Debian, est fausse.
D'ailleurs c'est un des gros soucis derrière les mauvaises utilisations de testing : la documentation à ce sujet n'est pas seulement lacunaire, elle est aussi souvent complètement erronée.
Hors ligne
Soit j'installe Buster en tant que Stable (c'est-à-dire en spécifiant stable plutôt que buster dans mon /etc/apt/sources.list), afin de basculer automatiquement sur Bullseye quand Buster deviendra Oldstable. Je suppose que c'est la façon officiellement recommandée de procéder.
Soit j'installe Testing en spécifiant bullseye dans mon /etc/apt/sources.list, afin de rester sur Bullseye quand elle deviendra la nouvelle Stable. Éventuellement, je pourrais aussi installer Sid et basculer sur Bullseye le moment venu.
Le freeze est en effet si proche... je me dis que Bullseye devrait assez peu changer d'ici son passage en Stable. Donc, au total, en termes de quantité de trucs à régler manuellement, il se pourrait bien que commencer sur Testing / Sid maintenant puis passer sur Stable dans quelques mois me donne moins de boulot que de migrer de Buster à Bullseye. J'ai bon ?
Qui plus est, Buster commence à accuser un peu son âge, par exemple pour le bureau Xfce que je compte installer et qui a pas mal avancé depuis (ainsi, je crois que la migration sur GTK 3 est encore inachevée dans la version offerte par Buster)... sachant que je viens d'Ubuntu LTS qui est un peu plus récent. Autant les mises à jour intempestives m'horripilent (je ne m'intéresserais pas à Debian autrement), autant je préfère éviter une rétrogradation des paquets.
Donc voilà où j'en suis, pour l'instant j'ai l'intention de voir ce que ça donne avec Bullseye Testing. Dans le meilleur des cas, si tout marche, je ne touche à rien et j'évite les mises à jour (pour ne rien casser) jusqu'à la sortie de Bullseye Stable. Si ça coince, j'essaye Sid... Dans tous les cas, je préférerais éviter d'avoir à tout réinstaller à la sortie de la prochaine Stable.
Merci pour vos avis !
Hors ligne
Aïe, ça a dérapé!
meu non, par rapport à certains fils du même genre, c'est resté zen !
Merci beaucoup pour toutes ces précisions en tous cas !
Hors ligne
Dans le meilleur des cas, si tout marche, je ne touche à rien et j'évite les mises à jour (pour ne rien casser) jusqu'à la sortie de Bullseye Stable.
Les màj ne cassent pas le système, et heureusement !
Je n'ai pas d'avis compétent à donner, seulement un fait : je met à jour à chaque allumage du PC et juste parfois des bug sans gravité qui ne durent pas longtemps (avec xfce, lighdm et firefox-esr).
Le freeze est en effet si proche... je me dis que Bullseye devrait assez peu changer d'ici son passage en Stable. Donc, au total, en termes de quantité de trucs à régler manuellement, il se pourrait bien que commencer sur Testing / Sid maintenant puis passer sur Stable dans quelques mois me donne moins de boulot que de migrer de Buster à Bullseye. J'ai bon ?
Tout bon
Quand le freeze est aussi proche, c'est plus simple à gérer d'installer la future stable et d'en suivre les (nombreuses) mises-à-jour correctives jusqu'à sa publication en stable. Si tu utilises bien le mot-clé "bullseye" plutôt que "testing" dans tes sources, ça devrait se passer sans diificulté notable.
Hors ligne