Reprise du message précédent :

 
Je dis pas, mais si les choses ne tombent pas rapidement au moins dans experimental (sachant qu'avant d'arriver à stable il y a encore Sid et testing), à quoi servent ces différents dépôts ? Je ne dis pas que si un auteur considère son soft stable alors c'est qu'il l'est obligatoirement, mais ne pas voir dans experimental des versions de softs éprouvées et utilisées par de nombreuses personnes, c'est un peu paradoxale je trouve.
 
@Dek : concernant les mélanges testing/Sid/experimental, je trouve ça presque normal que ça casse plus souvent que Arch stable, le mélange des branches est rarement encouragé pour des raisons de stabilité notamment (y compris sous Arch).

 
Tout à fait  

Une distrib ce n'est pas un soft, mais un ensemble de soft, qui doivent bien s'entendre, s'intégrer...
Alors qu'un soft soit stable dans sa dernière version est une chose, mais si il nécessite de mettre à jour tout un paquet de lib dont dépendent tout un paquet de logiciels, ben du point de vue de la distribution, c'est pas considérable comme stable.

C'est la distribution qui est considérée comme stable, unstable ou experimental, pas les logiciels qui sont dedans

Bien entendu. Mais a quoi sert un dépôt unstable (en pire encore, experimental) si les versions qu'il contient sont obsolètes ? Quelque part, si l'intégration d'un soft impose trop de mise à jour dans un dépôt expérimental, c'est peut être aussi que le dépôt mérite sérieusement d'être mis à jour dans son ensemble afin qu'il puisse remplir pleinement son rôle, à savoir permettre la détection de bug avant le versement des choses à peu près stabilisées dans unstable, puis testing, puis en dernier lieu stable. Enfin, ça reste un point de vue, je ne suis pas gestionnaire Debian, il y a peut être des raisons à tout ça, mais c'est en partie une des raisons pour lesquelles je suis parti sous Arch, du coup je me renseigne pour comprendre.

Ben oui, mais je pense pas qu'ils le nient, mais c'est du travail, alors si t'es pas satisfait du rythme propose toi pour les aider ça ira plus vite
Sinon tu fais comme tous les autres branleurs (moi y compris ) et tu ne dis rien

Pour KDE, si j'ai bien tout compris, c'est la release team de KDE qui a freiné les packageurs Debian pour la release. Par contre pourquoi ils ont fait ça...

OK, on peut pas faire une remarque sans se prendre un vieux do it yourself. Perso, je m'en fiche, je tourne pas sous Debian. J'émettais juste la remarque qu'il était surprenant de voir un dépôt experimental aussi peu à jour. Du coup j'avais la curiosité de savoir si cela était justifié et comment (peut être avec d'excellentes raisons, je dis pas).

Faut aussi comprendre que le mode de développement de Debian (Experimental/Sid/Testing et enfin Stable) a uniquement pour but la release de la Stable : que les branches au dessus soient complètement utilisables ou non, c'est secondaire vu que ça n'est pas le but premier.
Alors oui on peut utiliser une Sid comme une distrib en rolling-release, mais ça n'en est pas vraiment une (il y a des contraintes dictées par le mode de développement de Debian, par exemple quand Testing freeze, ben Sid aussi - les nouveaux paquets n'arrivent pas comme ça, il y a tout un processus) et c'est pas garanti que ça ne casse pas.

Donc on peut difficilement gueuler pour ça

ce n'est pas spécifique a debian.
Mais par exemple la sortie d'une application considéré comme  stable par l'auteur peut comme indiquée par e_esprit avec un certain nombre de conséquentes sur d'autres programmes situés en aval, tout simplement par exemple par que la « major » a changé ou autre. Bref les paquets dépendant d'une version précise ne peuvent tout simplement pas être a jour car il n'y a pas de mises à jour disponible « upstream ».
Exemple tout con pour un paquet que je maintiens chez mandriva, pyexiv2 qui a vu passé sa version stable en 2.x (au lieu de 1.x) , je ne peux pas me permettre de le mettre à jour par ce qu'au moins 2 paquets (que je maintiens aussi au hasard phatch et rapid-photo-downloader) ne fonctionne pas avec celle nouvelle version de pyexiv2. Il y a eu le même problème lors de la mise a jour de libexiv2 .
Bref il est un peu « trop » réducteur de voir un paquet « non » mise à jour dans un media testing/experimental/etc comme une faute grave du mainteneur, il fait simplement son boulot et vérifie qu'il ne va pas casser outre mesure le reste de la distribution.

j'ai bien du mal a comprendre pourquoi ils « freineraient » debian et pas les autres distributions là

Parce que Debian va trop vite

je pige pas trop les débats sur les probs de stabilité qui pousseraient les mainteneurs de KDE "Debian Sid" à faire du zèle ( KDE 4.3 qui bouge pas dans les dépots ) alors qu'à la base la version Sid n'est pas censée être hyper stable et que l'une des principales raison de l'utilisation de la "Sid" c'est d'avoir une sorte de "rolling release" à la Arch ( c'est pas clairement défini comme ça sur le site de Debian mais c'est tout comme )

les mainteneurs de Debian ont-ils des comptes à rendre sur la qualité de leur travail ? ( un contrat d'objectif, des règles à suivre, une charte de qualité à respecter )

genre si le big boss de Debian s'aperçoit que le préposé à la maintenance de Debian Sid fait mal son boulot ben hop il est remplacé par quelqu'un de plus réactif ?
 
comme ça plus de soucis avec les releases de KDE qui tardent à arriver chez Sid alors que le truc a été testé mille fois par les bétas-testeur de KDE et que cette version a reçu le label "stable officiel  chez KDE ( des milliers de bugs corrigés entre la branche 4.3 et 4.4, il y a peu de chances que l'expérience utilisateur soit pire avec la 4.4 qu'avec la 4.3, il ne peut y avoir qu'un gain positif en grande majorité    )

Relis les posts au-dessus

Oulalala... quand je lis des trucs pareils   , j'ai vraiment envie de recadrer un peu les choses, ce que je vais faire ici ; alors voyons quelques points :
 
 
- Tout d'abord, quel est le but principal du projet ?
 
Les releases stable (à savoir une release où l'intégration et l'interaction entre paquets y est optimale, avec un minimum de bugs). Pour y parvenir, on utilise unstable (dépôt pour la mise au point/debuggage des paquets) et testing (dépôt "tampon" où les paquets qui entrent sont filtrés selon certains critères concernant la qualité d'intégration et la sévérité des bugs qu'il contiennent) -c'est le fameux mode de développement basé sur des branches (que plein de toutes les grosses distros ont d'ailleurs chacune repris à leur sauce au fil du temps, preuve que ce système est pas si pourri que ça   ).
 
Le rythme de mise à jour des dépôts testing et unstable dépend de nombreux paramètres : releases en upstream, travail d'intégration/debug plus où moins long/important (dépendant en partie de la qualité des releases upstream), gestion des dépendances complexes (dans le cas de gros ensembles de paquets) pour que fonctionnent les scripts de migration auto de unstable vers testing, temps de construction des paquets, etc., etc. Mais faut surtout jamais perdre de vue que le paramètre principal là-dedans, c'est qu'on est dans la dynamique d'une release dite stable à un instant T et cela change toute la donne, car l'optique d'une sortie à moyen/long terme oblige vraiment à s'assurer de bonnes bases pour que le travail d'intégration soit tout simplement faisable (rien à voir avec une rolling-release, c'est du court terme : on s'en fout à la limite de tout péter à un instant T puisque les versions se succèdent sans cesse et vont plus ou moins rapidement corriger les merdes actuelles ou les empirer encore un peu plus   ).
 
Précisons aussi que la release stable se doit d'être fonctionnelle non pas juste pour 1 ou 2 architectures (cas de Arch), mais pour pas moins d'une dizaine ; ça rajoute aussi une contrainte supplémentaire et de taille (ne serait-ce que du seul point de vue du nombre de paquets à maintenir), sans compter certains portages spécifiques (noyau kfreebsd ; je vous épargne Hurd, hein, on parle d'un truc qui sera un jour utilisable   ). On est à des échelles bien différentes, et pour ainsi dire pas vraiment comparables.
 
 
- Ensuite, c'est quoi réellement experimental ?
 
Compte tenu de son caractère partiel, on ne peut vraisemblablement pas parler d'une branche à part entière, mais plutôt d'un dépôt servant de bac à sable pour les développeurs. En effet, il n'est pas possible d'installer une version de Debian intégralement à partir de experimental car seuls certains paquets y figurent et en aucun cas la totalité de l'archive ; il n'y a aucun lien direct entre unstable et experimental : aucun système de migration n'existe entre eux et les paquets sont traités au cas par cas (experimental peut servir de zone transitoire quand un paquet induit un risque de casse trop élevée -même pour unstable- ou lors d'une période de freeze pour que le travail puisse continuer, mais il arrive aussi que des paquets placés dans experimental n'entrent jamais dans unstable). Conlusion : experimental est un cas bien à part, et ne peut être considérer comme faisant partie intégrante du cycle de développement suivi par Debian contrairement à ce qu'on pourrait imaginer parfois.
 
 
Enfin, pour terminer, notez quand même que KDE est disponible en version 4.4.1 dans experimental ; alors OK, c'est pas la toute toute dernière version dispo (la 4.4.2 en upstream), mais bon ça laisse de quoi se faire une bonne idée si l'on trouve déjà trop obsolète la version 4.3.1 de unstable (si on garde à l'esprit tout ce que j'ai indiqué plus haut, on comprendra peut être mieux pourquoi les mainteneurs Debian vont pas tirer comme ça un trait sur tout le travail d'intégration qui a été effectué jusqu'à présent depuis septembre 2009, date de release de cette version de KDE en upstream, en vue de la future release stable de Debian).
 
Voilà, en espérant avoir quelque peu éclairer vos lanternes.  

   
 
+ le topic en première page au passage concernant le fonctionnement du projet (cf. contrat social & co), ça peut aider à éclaircir les choses.

Très bon éclaircissement THRAK  

Merci THRAK pour cette remise en situation. L'éclaircissement sur le rôle apporte pas mal de choses concernant l'utilité du dépôt experimental. Mais quand même, c'est pas à jour

Ah oui, donc c'est plutôt normal que le kernel 2.6.33 n'ai pas son header kbuild dans experimental

Dites je me retrouve ce matin avec un joli arrêt de mon relais antispam + proxy....causé par un "end of life" de ma version de clamav fournie avec Lenny./ C'est nouveau ce genre de surprises?

non.

edit : blame clamav

Ah c'est bon, la version de debian-volatile est à jour, j'ai eu peur

oui j'ai du passer vite fait sur volatile, et dansguardian risque de devoir subir le même sort (il ne s'entend pas avec la libclamav6...)  

De toutes façons pour clamav, et pour les applis de ce type (MAJ régulières et importantes) il est fortement conseillé d'être sur debian-volatile

Merci.    

Et oui, bon exemple : ici on a une dépendance requise de kbuild pour les headers du noyau 2.6.33 qui n'est pas satisfaite ; donc c'est pas normal en soi, mais c'est pas pour rien que c'est dans experimental.  

 
 
Je me suis retrouvé dans la meme Mer** hier matin avec une redhat AS4 ....

concernant clamav je préfère compiler directement les sources ( on peut même le faire de manière à ce que seul le scanner antivirus fonctionne manuellement, pas de daemon, c'est utile si on cherche uniquement à scanner à la main occasionnellement des mails ou des fichiers exe à destination de PC sous Windows )

et pour éviter de toucher au système je mets l'installation de clamav dans un repertoire autre que usr/* ( configure --prefix=/mon repertoire hors système )

Idem sur un serveur mail de prod ! Ca fait toujours plaisir.

non

Blame clamav, bof pas vraiment. Blame sysadmin plutôt.
C'est quand même annoncé depuis octobre dernier.

Tu mets un produit en prod, tu te tiens informé, ça fait parti du taf.  

 
Ne plus fournir de MaJ OK, mais envoyer une MaJ pourrie qui casse volontairement le daemon (en le faisant planter ) je suis pas trop d'accord

d'ailleurs vendredi matin le site de clamav était complètement dans les choux ...
 

Hello tout le monde,
 
Dites, depuis plusieurs jours/semaines, il n'y a aucune mise a jour de dispo pour ma Debian sur mon Slug. Je trouve ca etonnant, je me demande si j'ai pas un probleme...

C'est une Etch, plus supportée

Etch n'est plus supporté depuis le 15 février 2010.

j'en connais qui vont être content, à refaire leurs serveurs de prod parce que plus supporté  

refaire est un bien grand mot, dans 95% des cas un aptitude dist-upgrade suffit

Et puis Etch est sortie il y a un peu plus de 3 ans à présent ; niveau durée du support, c'est pas mal tout de même, d'autant qu'une release oldstable est maintenue encore pendant une bonne année après la sortie d'une nouvelle stable, de quoi migrer en douceur ses serveurs de prod.

 
Bof,
depuis que je l'utilise, clamav affiche des messages plus où moins alarmants pour rien... par contre avant d'arrêter de fonctionner, quedalle, rien, même pas une carte....  C'est un peu barbare comme méthode, mais effectivement, c'est ma faute.  
 

c'est mieux la, apres un aptitude dist-upgrade

Merci de vos reponses en tout cas

C'est pareil avec toutes les distribs hein
Si ce n'est que les payantes maintiennent un peu plus longtemps
 
Pis bon, ça m'empêche pas d'avoir encore une sarge qui fait très bien ce qu'elle est censée faire