Voilà : ma bécane est un simple poste de travail, qui n’accueille pas de serveur et sert exclusivement à un usage familial. Je suis actuellement, et depuis quelques jours seulement, sous Debian sage 3.1r2 et je me demande déjà s’il ne faut pas que j’upgrade ma Debian vers une testing. Je remarque, en effet, que les packages, bien que très stables, sont quand même anciens, qu’en conséquence e rencontre des problèmes pour faire de mon ordi un stations audio/vidéo qui ne déroute pas mes gamins. En effet, difficile de lire un Ipod ou d’encoder en mp3 (sauf à installer à la main les sources lame, etc.). et les plugins nécessaires au bon fonctionnement de DVDRip (par exemple) ne sont pas tous dispos en sarge stable main. Parlons également des derniers thèmes proposés sous Gnome : certains demandent pour fonctionner correctement des packages plus récents et plus diversifiés que ceux proposés en sarge stable.
Bref, et n’y voyez aucune critique envers la sarge, mais j’aimerais pouvoir bénéficier de paquets plus nombreux et plus récents, vu l’usage que je fais de mon ordi. Cette longue intro étant faite, la testing pose-t-elle moins de problèmes pour le paramétrage et une utilisation multimédia ? Deux : pour upgrader mon OS, me suffit-il de remplacer dans /etc/apt/sources.list les mots “stable” par “testing” ? Merci d’avance.
Si tu ne veux pas passer ton temps à réparer ce qui à cassé à la suite d’un upgrade de paquets, un bon conseil: reste en stable …
Sur la testing, les upgrades sont très souvent foireux. Au final, tu passes plus de temps à réparer la casse qu’à utiliser ton poste.
Je suis moi-même en stable et j’utilise mes postes principalement pour faire
du multimédia:
1.Acquisition TV (freevo + carte de capture TV)
2.Acquistion Firewire sur mon camescope
3.Acquistion de mes photos numériques
4.Encodage mpeg en divx/xvid et autres
5.Encodage mp3/ogg/FLAC …
6.Traitement d’images …
Et ainsi de suite…
C’est vrai que tu as la dernière release des softs si tu passes en testing mais utiliseras-tu vraiment les dernières fonctionnalités de ces packages instables ?
Mais bon, à chacun sa politique, en ce qui me concerne, j’installe la testing uniquement… pour faire des tests ! 
J’ai horreur de devoir réparer mon installation quand c’est samedi soir et qu’il est l’heure de regarder le film, par exemple …
Et si tu veux vraiment la dernière fonctionnalité d’un soft, tu as toujours la possibilité de le compiler à partir des sources. (Aie, les autres ! pas sur la tête s’il vous plaît ! 
)
D’une pierre 2 coups:
- Tu ne touches pas ton système de packaging Debian
- Tu isoles complètement ton nouveau soft (dans /usr/local/ par exemple) du reste du système.
Merci Jabba. Si je demandais conseil, c’est justement parce que je redoute, en testing, de trop galérer. Or, une fois en testing, il est impossible de revenir en sarge, sauf à tout réinstaller (non merci !!!). Du coup, je retiens ton conseil d’installer les tar.gz en les dissociant des paquets deb stables. Dans ce cas, je suppose qu’il faut passer par un ./configure --prefix=/usr/local
Ensuite, pour l’encodage mp3, as-tu installé les sources lame en tar.gz ? Faut-il ajouter au ./configure des options particulières ? J’aimerais que goobox puisse y recourir. Je trouve ce soft d’une grande rapidité, comparé à sound-juicer
Pour les thèmes Gnome, je crois qu’il me sera nécessaire d’installer le package source de GTK+ et ses dépendances (atk, etc.)
Enfin, me conseillerais-tu d’upgrader un/ mon kernel de la v2.6.8.2.386 vers la 2.6.15. ; deux / Python de la v2.3 vers la v2.4 ? Je crois, mais je ne suis pas devant mon ordi, que la sarge n’intègre que la v2.3.
un conseil, si tu veux passer en testing depuis une stable, aussi paradoxale cela puisse paraitre, passe D’ABORD en unstable.
et ensuite reviens avec des depots testing.
pourquoi? comme déjà souvent mentionné sur ce même forum, il y a réguliérement des dépendances manquantes en testing ce qui n’est quasiment jamais le cas en unstable (et si cela arrive, en général le paquet est dispo en testing).
FYI, voici mes fichiers pour les dépôts:
[quote="/etc/apt/sources.list"]
TESTING / ETCH
deb ftp.fr.debian.org/debian testing main contrib non-free
deb ftp.debian-unofficial.org/debian/ testing main contrib non-free restricted
deb ftp://ftp.nerim.net/debian-marillat/ etch main
deb security.debian.org/ testing/updates main contrib non-free
UNSTABLE / SID
deb ftp2.fr.debian.org/debian unstable main contrib non-free
deb ftp.debian-unofficial.org/debian/ unstable main contrib non-free restricted
deb ftp://ftp.nerim.net/debian-marillat/ sid main[/quote]
[quote="/etc/apt/preferences"]
Package: *
Pin: release a=testing
Pin-Priority: 600
Package: *
Pin: release a=unstable
Pin-Priority: 90[/quote]
ainsi aisement je peux passer de unstable a testing et vice/versa en mettant tout simplement une priorité pour l’unstable > à la priorité de testing (690 par exemple), le tout suivi d’un apt-get update bien evidemment.
v’là mon point de vue sur la chose.
il y a aussi les backports si tu tiens à rester en sarge avec certaines applis à jour (faire une recherche sur ce même forum sur le mot clé BACKPORTS).
cheers.
Jabba: tu exagères un peu l’instabilité de la testing, tout de même.
bpier: pour un usage VRAIMENT familial, c’est à dire avec des utilisateurs pas forcément technique (d’autres utilisateurs que toi 
), l’avis de Jabba me semble frappé au coin du bon sens.
Par contre, il a oublié de te dire l’essentiel: oui, tu va devoir installer les softs “bleeding edge” dont tu as besoin en les compilant avec le traditionnel ./configure;make;make install, mais il a oublié de te signaler que même en compilant, tu peux informer apt des fichiers installés pendant la phase du ‘make install’ en installant et en utilisant checkinstall. La syntaxe de la dernière étape devient alors ‘checkinstall make install’, et tu ne risque plus d’ecraser quoi que ce soit en installant un paquet debian qui auraient des fichiers communs avec tes builds.
Sinon, pour le --prefix=/usr/local (je pencherais plutôt pour --install-prefix), ça me semble être logique, mais AMA, il vaut mieux faire un ./configure --help, et si c’est bien fait, tu devrais connaitre un peu plus précisément les options (qui doivent varier suivant les softs). Parfois aussi, le configure se paramètre par le passage de variables d’environnement, genre:
CC=/usr/bin/gcc-3.3 ./configure
Et je viens de voir le post de ghost: l’utilisation de backports est aussi une bonne alternative, mais là, on perd le coté “install séparée dans /usr/local”, et souvent, on se retrouve avec le même type d’inconsistances entre paquets qu’en passant en testing, même si les paquets du coeur restent plus stables.
oui, 'fin bon, si ça peut en rassurer certains, ça va faire 9 mois que j’utilise Debian en testing/unstable comme machine principale (desktop / home station).
il n’y a reellement qu’une seule fois ou j’ai eu des stress, c’etait lors d’une grosse mise a jour testing justement! j’ai cherché de midi à 14h et finallement en passant temporairement en unstable, tout etait reglé! il ne me suffisait plus alors qu’à revenir à des depots testing et attendre tranquillement les futures mises à jour …
vlà!
PS/ 'faut pas croire qu’une Mandriva, une Fedora et même une Ubuntu sont plus stables qu’une Debian testing/unstable … loin de là même! si je devais par ailleurs utilisé une Debian stable, je n’utiliserais tout simplement pas Debian! ++
quote="ghostintheshell"
ainsi aisement je peux passer de unstable a testing et vice/versa en mettant tout simplement une priorité pour l’unstable > à la priorité de testing (690 par exemple), le tout suivi d’un apt-get update bien evidemment.
v’là mon point de vue sur la chose.[/quote]
Bon, c’est pas le forum pause café, et c’est donc un peu hors sujet, mais je ne suis pas d’accord: pour le passage de stable en sid, d’accord, une priorité superieure pour la sid suffit (et même “pas de prio” fonctionne aussi), mais pour le downgrade, les paquets upgradés en sid ne descendront pas necessairement en etch, même avec une priorité supèrieure pour l’etch: il faut une priorité superieure à 1000 pour qu’un paquet subisse un downgrade de version, ou bien peut être passer un argument genre --force-downgrade en ligne de commande lors de l’upgrade. Un ordre de priorité ne suffit pas à provoquer un downgrade de paquet.
Si tu crois ça, ghost, alors peut être que tu es encore en sid sur certains paquets, sans le savoir 
quote="ghostintheshell"
il n’y a reellement qu’une seule fois ou j’ai eu des stress, c’etait lors d’une grosse mise a jour testing justement! j’ai cherché de midi à 14h et finallement en passant temporairement en unstable, tout etait reglé! il ne me suffisait plus alors qu’à revenir à des depots testing et attendre tranquillement les futures mises à jour …(…)[/quote]Oui, mais…
Le problême n’est pas tant que la machine soit stable dans son exploitation, ce qui est le cas même en sid, mais que la machine soit stable LORS D’EVENTUELS UPDATE, comme l’a fait justement remarquer Jabba.
quote=“MattOTop” les paquets upgradés en sid ne descendront pas necessairement en etch, même avec une priorité supèrieure pour l’etch: (…)
Si tu crois ça, ghost, alors peut être que tu es encore en sid sur certains paquets, sans le savoir [/quote]
ce a quoi je repondrais;
tout à fait ET justement là est tout l’interet pour resoudre les problemes de dependances en testing (comme expliqué)!
et, oui, je sais: Debian GNU/Linux testing/unstable !!
ce qu’il faut se dire et savoir est que TESTING est véritablement une phase de transition et est à mon goût parfois bien plus instable (au niveau des dependances en tout cas, pas des paquets en eux-memes) que l’unstable!!
'fin bon …
[quote=“MattOTop”]quote=“ghostintheshell”
il n’y a reellement qu’une seule fois ou j’ai eu des stress, c’etait lors d’une grosse mise a jour testing justement! j’ai cherché de midi à 14h et finallement en passant temporairement en unstable, tout etait reglé! il ne me suffisait plus alors qu’à revenir à des depots testing et attendre tranquillement les futures mises à jour …(…)[/quote]Oui, mais…
Le problême n’est pas tant que la machine soit stable dans son exploitation, ce qui est le cas même en sid, mais que la machine soit stable LORS D’EVENTUELS UPDATE, comme l’a fait justement remarquer Jabba.[/quote]
justement, c’est ce que j’essaie d’expliquer depuis 30 minutes …
TESTING = instable % dépendances -> parfois, il est necessaire de temporairement passer par l’UNSTABLE (quitte à se retrouver avec quelques paquets UNSTABLE qui finiront quand-même par passer en TESTING à un moment ou un autre)
UNSTABLE = instable % paquets -> la raison pour laquelle je reste en TESTING
OK?? 
et pour conclure, je dirais même plus que le cas extreme est celui-ci:
probleme de dependances en TESTING
-> passage temporaire en UNSTABLE
-> probleme de dependances réglé MAIS probleme avec un paquet!
et là c’est la m*rde 
ça m’est arrivé y’a pas longtemps avec le paquet xorg mais tout est tres vite rentré dans l’ordre … je rassure, c’est un cas extreme et ça m’est arrivé une seule fois en 9 mois …
bon. bon joujou avec vos dépôts 
[quote=“MattOTop”]Jabba: tu exagères un peu l’instabilité de la testing, tout de même.
[/quote] Un tout petit peu alors … 
Et je persiste à dire que installer la testing/unstable pour faire autre chose que tester ou simplement assouvir sa curiosité… C’est chercher la m…
[quote=“MattOTop”]
Par contre, il a oublié de te dire l’essentiel: oui, tu va devoir installer les softs “bleeding edge” dont tu as besoin en les compilant avec le traditionnel ./configure;make;make install[/quote]
Ah ben non, ça je l’ai dit hein qu’on pouvait compiler depuis les sources ! 
PS:je suis content moi, c’est la 1ère fois que j’arrive à placer le petit smiley qui vomit … 
quote=“jabba”
Et je persiste à dire que installer la testing/unstable pour faire autre chose que tester ou simplement assouvir sa curiosité… C’est chercher la m… (…)[/quote]
pas d’accord 
c’est juste une question d’un peu de doigté et de pas mal d’expérience de terrain “testing/unstable”
je vous le dis et le répete: il ne faut pas se braquer sur la testing OU l’unstable, les deux vont de pair, il faut jongler / jouer avec les 2, la testing pour utiliser des paquets relativement stables en version récente et l’unstable pour résoudre le problème de dépendance entre paquets (ce qui arrive relativement réguliérement en testing, surtout lors de grosse mise à jour).
et si tu te bornes a utiliser que la testing ou que l’unstable, alors oui, je te soutiens dans ton affirmation, c’est chercher la m…!
Jabba: tu avais bien parlé de compiler depuis les sources, mais tu avais oublié de parler de checkinstall, qui est tout de même un peu la clé de la réussite de cette méthode.
ghost: j’ai tous les types d’installs, mixtes, avec des builds, tout recompilé, etc, sur une dizaine de machine maintenant, et je ne suis pas du tout d’accord avec toi.
C’est déjà difficile de faire admettre en famille l’utilisation de linux (papa: pourquoi je peux pas utiliser encarta ? ) alors si tu ajoutes par dessus le moindre soucis de mise à jour, ou des pitites rigolades comme mon kwallet sur mon etch qui fonctionne une fois sur 2, ou une foultitude de navigateurs différents, avec certains qui prennent bien les contenus embedded, d’autres non, etc… Tout ça dans un cadre familial, tu te retrouves dans une situation limite sanglante: ma machine perso qui sert à beaucoup de mes tests avancés, est dans le salon, et ne marche jamais quand ma femme veut s’en servir. Elle a fréquenté suffisament d’OS different pour ne pas être choquée par un linux, mais je peux te dire que les dix minutes pour retrouver quel player est correctement configuré, quand elle veut écouter de la musique à l’heure de l’apéro avec des copines, ça passe moyen moyen…
Et moi, et moi et moi, comme chantait Dutron !!! Vous m’avez oublié… Alors, je retiens qu’il serait bon que reste en sarge. Pour le moment, en tout cas (je suis passé à Debian il y a cinq/six jours, je rappelle). Mais, cela posé, vaut-il mieux utiliser les paquets Backport ou recourir à la bonne vielle méthode des tar.gz : ./configure, make et make install ? A priori, je comprends qu’en séparant ces paquets non deb des autres et en les plaçant dans /usr/local, on fout la merde sur son ordi en cas de mises à jour des softs par apt-get. C’est bien ça ?
Ensuite, comment vous avez fait pour réussir à encoder en mp3 ? C’est pas pour moi, Debian lit les formats libres et puis k3b sait les convertir en audio. Mais c’est pour les gamins qui, eux, n’utilisent que ça.
Je dois ajouter qu’Alsa fonctionne bien chez moi, sans devoir le relancer à chaque démarrage, qu’xmms lit presque tous les formats (j’ai pas encore installé les plug Win32), que streamtuner et streamripper font leur boulot (streamripper encode en mp3 d’ailleurs, encore une étrangeté pour moi, puisque Goobox ne sait pas encore le faire)
Enfin, ça vaut le coup d’upgrader mon kernel vers le 2.6.15 ou pas ?
Merci d’avance les gars. Pierre
[quote=« bpier »]Et moi, et moi et moi, comme chantait Dutron !!! Vous m’avez oublié… Alors, je retiens qu’il serait bon que reste en sarge. Pour le moment, en tout cas (je suis passé à Debian il y a cinq/six jours, je rappelle). [/quote]Si ca fait si peu de temps tu peux rester sur une stable meme si la testing n’est plus si unstable que ca c’est un peu a toi de voir la[quote=« bpier »]Mais, cela posé, vaut-il mieux utiliser les paquets Backport ou recourir à la bonne vielle méthode des tar.gz : ./configure, make et make install ? A priori, je comprends qu’en séparant ces paquets non deb des autres et en les plaçant dans /usr/local, on fout la merde sur son ordi en cas de mises à jour des softs par apt-get. C’est bien ça ?[/quote]Oula 
il vaut mieux eviter l’install par tar.gz mais si tu ne peux pas faire autrement alors il faut faire ./configure
make
checkinstall make installCa evite d’écraser les fichiers dont tu as besoin pour le prog avec aptitude ou apt-get[quote=« bpier »]
Ensuite, comment vous avez fait pour réussir à encoder en mp3 ? C’est pas pour moi, Debian lit les formats libres et puis k3b sait les convertir en audio. Mais c’est pour les gamins qui, eux, n’utilisent que ça.
Je dois ajouter qu’Alsa fonctionne bien chez moi, sans devoir le relancer à chaque démarrage, qu’xmms lit presque tous les formats (j’ai pas encore installé les plug Win32), que streamtuner et streamripper font leur boulot (streamripper encode en mp3 d’ailleurs, encore une étrangeté pour moi, puisque Goobox ne sait pas encore le faire)
Enfin, ça vaut le coup d’upgrader mon kernel vers le 2.6.15 ou pas ?
Merci d’avance les gars. Pierre[/quote]Pour l’encodage aucune idée dsl et pour le nouveau noyau pourquoi pas tu a la méthode la forum.debian-fr.org/viewtopic.php?t=1806&start=0
Merci Ashgenesis. Voilà qui répond à plusieurs de mes interrogations. Si je ne peux faire autrement, je passerai donc par les tar.gz, en prenant soin d’user du checkinstall. Pour l’install d’un kernel-2.6.15, ça me paraît nécessaire pour la bonne reconnaissance du hardware. Je suivrai bien évidemment la méthode Debian. Pour l’encodage, je viens de repérer un dépôt non officiel : rzr.online.fr/debian/ où l’on trouve un lame-XXXX.deb.
J’essaierai en l’ajoutant à mon sources.list via un “wget -O- rzr.online.fr/docs/contribs/sources.list >> /etc/apt/sources.list” ,à moins qu’on me le déconseille. Pierre
un paquet lame est disponible dans les dépots marillat
ash@seal:~$ sudo apt-cache policy lame
lame:
Installed: 3.97beta2+debian-1duo+sarge1
Candidate: 3.97beta2+debian-1duo+sarge1
Version table:
*** 3.97beta2+debian-1duo+sarge1 0
100 /var/lib/dpkg/status
3.96.99+3.97beta2+debian-1duo+sarge1 0
550 http://ftp.debian-unofficial.org sarge/main Packages
3.96.1-1 0
550 ftp://ftp.nerim.net sarge/main Packages
550 ftp://ftp.nerim.net etch/main Packages
tu peux rajouter dans ton sources.list les lignes suivantes deb ftp://ftp.nerim.net/debian-marillat/ sarge main
deb http://ftp.debian-unofficial.org/debian sarge main contrib non-free restrictedet faire juste apres un apt-get update pour mettre a jour la liste des paquets disponibles