Salut à tous.
youtube-dl, possède en interne un système de mise à jours.
Vous pouvez utiliser la mise à jours interne du logiciel avec cet commande: youtube-dl -U (attention majuscule).
En ce moment, sous la testing actuel (wheezy), il y a un bug.
Il n’y a pas de nouvelle version pour upgrader sous debian testing (wheezy).
Un des moyen efficace et fonctionnel est d’utiliser directement le système de mise à jours du logiciel qui résout le problème.
[quote=“kripteks”]En ce moment, sous la testing actuel (wheezy), il y a un bug.
[…]
Il n’y a pas de nouvelle version pour upgrader sous debian testing (wheezy).[/quote]
Le moyen efficace et fonctionnel de gérer une testing, c’est de piocher des paquets dans unstable lorsqu’il y a un bug gênant dans testing. Tout le reste n’est qu’un emplâtre sur une jambe de bois.
[size=150]Pour rappel : testing n’est pas faite pour être utilisée seule ![/size]
Comme par hasard le bug que tu décris est déjà corrigé dans unstable : bugs.debian.org/cgi-bin/bugreport.cgi?bug=688997
Le nouveau paquet était disponible dans unstable dès le lendemain de la publication de la nouvelle version upstream, pour testing y’a plus qu’à attendre que ça descende normalement.
Et si t’est pressé : aptitude install youtube-dl/unstable
$ apt-cache policy youtube-dl
youtube-dl:
Installé : (aucun)
Candidat : 2012.02.27-1
Table de version :
2012.09.27-1 0
802 http://ftp.debian.org/debian/ unstable/main amd64 Packages
2012.02.27-1 0
902 http://ftp.debian.org/debian/ testing/main amd64 Packages
C’est juste une petite astuce du système d’update interne du logiciel. Et c’est pour cela que j’ai mis le problème testing au deuxième post, ce qui de plus temporaire.
Sinon je sais que sous sid y a une nouvelle version, mais moi ma politique: wheezy et rien d’autres (sid/experimental) tant que c’est par très urgent, et c’est presque toujours stable sous cette forme.
Dans tout mes installation avec le mélange squeeze/sid, wheezy/sid => passage sid, c’est vraiment bien sid, mais sa devient vite unstable comme son surnom et sa me surpasse, je sais qu’il y a aptlistbug mais moi quand j’ai besoin d’un logiciel à installer, faut que je l’installes.
Que tu choisisses d’utiliser testing d’une manière qui n’est pas du tout prévue par Debian, c’est ton choix et il n’y a rien à y redire, apparemment tu sais ce que tu fais.
Le problème n’est pas par rapport à ton astuce elle-même, mais au fait que certaines personnes moins bien informées que toi pourraient prendre ça comme une bonne méthode pour gérer leur testing de manière générale. D’où l’avertissement en gros caractères rouges pour leur rappeler qu’une testing fonctionnelle c’est :
- priorité aux dépôts testing
- dépôts stable et unstable en complément pour pouvoir piocher dedans en cas de problème sur testing (ce qui arrive très souvent)
Je serais d’ailleurs bien curieux de savoir comment tu fais lorsque tu constates un bug bloquant après une mise à jour de ta testing… Tu gardes le bug pendant au moins une semaine (au mieux) le temps que ça redescende depuis unstable, quitte à ne pas pouvoir utiliser le logiciel concerné ?
Ah je comprends.
Pour les bug, j’utilises toujours le minimal requis, des logiciels simple qui sont presque toujours stable, pas de gros changement voir aucun pour certains et donc les risques sont petit.
Oui c’est sûr que si te te contentes de logiciels “simples” comme ceux dans ta signature ça réduit déjà beaucoup les risques. 
Mais méfie toi tout de même, il arrive de temps en temps que ça soit les couches basses du système qui sont concernées par un bug (le fameux “Xorg 100% utilisation CPU” par exemple il y a quelque temps, beaucoup de monde a été touché par ça et la seule manière de le résoudre était de réinstaller des paquets stables ou en provenance des snapshots).
Si tu restes sur testing à long terme, tu n’y couperas pas…