Garder un système stable

Support Debian
#1

Bonjour à tous.

Je suis en train d’essayer Debian et je dois dire que je ne comprend pas tout à la philosophie stable/testing/unstable.
Comme je suis plus à l’aise sous Gentoo, je vais expliquer ce que je compte faire à la façon gentoo.

J’ai actuellement un système 100% “stable”. Or dans mon cas ce n’est pas si stable que ça, puisque Firefox plante à tout bout de champ dès que des fonctions Javascript tordues sont appelées. Avec la version testing ( 1.5 ) il n’y a apparement pas de soucis ( testé sur une autre machine ).

J’aimerai mettre à jour uniquement Firefox.
Sous gentoo, j’aurai ajouté le keyword “mozilla-firefox ~x86” pour accepter les versions “testing” de ce paquet.
Je ne sais pas arriver à ce résultat sous Debian. Lorsque je rajoute dans sources.list une ligne “testing” ; et bien le moindre apt-get me met à jour X, Gnome, etc… Ce qui fait que je me retrouve avec un système entièrement “testing”. Ce n’est pas ce que je veux.
Comment dois-je faire ?

Voilà, j’espère avoir été assez clair. Merci d’avance pour vos réponses.

#2

man apt_preferences
et tu pourra aussi t’inspirer des quelques exemples qui existent sur le forum quand aux preferences.

#3

Haem… Un fichier préférences très basique a l’air d’être ce qu’il me faut.

J’ai donc empeché ( dans le fichier preferences ) que apt installe des deb en testing.

Et j’essaye donc : “apt-get install firefox/testing”

Il me sort une liste de dépendances assez monstrueuse, qui finalement revient à faire un upgrade de tout le système en “testing”.

En fait j’aurai du commencer par installer une Echt au lieu d’une Sarge si j’ai bien compris ?

( en fait c’est pour faire un Terminal Server… Donc me faut de la stabilité, mais aussi des applications qui fonctionnent au gout du jour :frowning: )

#4

en fait, non: il faut non seulement dire que tu ne veux que du stable, et préciser que pour telle ou telle appli, tu veux de l’etch.
La commande d’install n’aura plus besoin de preciser la version que tu souhaites. Celle que tu as utilisée: apt-get install /testing va provoquer effectivement l’install du pkt, et DE TOUTES SES DEPENDANCES EN TESTING MÊME SI ELLES SONT SUFFISANTES EN STABLE.
Pour ce qui est de changer de release, pas besoin de réinstaller: avec les prefs, tu peux passer de l’une à l’autre sans tout reconfigurer. La difference essentielle entre la stable et la testing, c’est surtout la correction des failles de sécurité. Si ton problême n’est pas d’assurer de la sécurité, mais d’avoir une version propre et récente des softs, tu peux passer en testing.
Files un peu ton sources.list et tes preferences ?

#5

forum.debian-fr.org/viewtopic.php?t=1728

Matt tu as oublié ce lien :smiley:

Ca explique pas mal de choses mais je pense en refaire un plus complet/xe

#6

[quote=“Ashgenesis”]http://forum.debian-fr.org/viewtopic.php?t=1728

Matt tu as oublié ce lien :smiley:

Ca explique pas mal de choses mais je pense en refaire un plus complet/xe[/quote]Il faut aussi prendre en compte la nouvelle possibilité d’éclater le sources.list dans sources.list.d .
Par ailleurs, j’ai beau avoir des preferences peaufinées, et avoir bien chopé le rôle des prios >1000 et <-1 et leur usage pour “cleaner” des machines, je ne vois pas vraiment de différences dans les valeurs intermèdiaires, à partir du moment ou l’ordre de prio est respecté.
Tu vois ce que je veux dire ?
(désolé d’ouvrir un peu le fil).

#7

[quote=“MattOTop”][quote=“Ashgenesis”]http://forum.debian-fr.org/viewtopic.php?t=1728

Matt tu as oublié ce lien :smiley:

Ca explique pas mal de choses mais je pense en refaire un plus complet/xe[/quote]Il faut aussi prendre en compte la nouvelle possibilité d’éclater le sources.list dans sources.list.d .
Par ailleurs, j’ai beau avoir des preferences peaufinées, et avoir bien chopé le rôle des prios >1000 et <-1 et leur usage pour “cleaner” des machines, je ne vois pas vraiment de différences dans les valeurs intermèdiaires, à partir du moment ou l’ordre de prio est respecté.
Tu vois ce que je veux dire ?
(désolé d’ouvrir un peu le fil).[/quote]Oui je vois ce que tu veux dire c’est d’ailleurs l’une des raisons pour laquelle j’ai bien envie de revoir un petit tutos dessus et ca me permettera en prime d’etre un peu plus confortable sur ce sujet.

#8

Alors je viens d’essayer ça… Ca a l’air d’être ce que je veux.

Mais finalement mon problème n’a pas l’air d’être d’un problème de paramètrage mais plutot de dépendances. Ici le réseau de dépendances semble tellement “profond” que tout finit par passer en testing ( ou au moins ce que je ne voulais pas, c’est à dire X et Gnome ).

Enfin bref, merci quand même je pense avoir compris le principe. Je vais sans doute tout passer en testing.

#9

Firefox tire tant de dépendances que ça ? :cry:

#10

J’oublie toujours mais il y a aussi les backports.
Il y a même un fil qui explique comment les fabriquer.
Mais pour firefox, si ça tire tant de dépendances…

#11

Hop fausse alerte :smiley:

Je viens de mettre à jour Firefox ( une mise à jour qui vient probablement de sortir :open_mouth: 1.0.4-2sarge11 en stable ) et je n’ai plus de bug avec mes menus javascript.

Je vais donc, je pense, rester en stable sans rien toucher. C’était mon seul problème “bloquant”.

#12

Oui il y a un backport.

backports.org/debian/pool/main/f/firefox/

En gros ca a été recompilé avec les libs de stable, enfin si j’ai bien compris :slightly_smiling:

#13

C’est quoi un “Terminal Server” ?

#14

Euh… Dans ma boite j’ai tout un tas de terminaux passifs qui accèdent au dit serveur via Vnc.

Sur le serveur je lance Xvnc en tant que service et tout le monde arrive sur un environnement différent.

Aujourd’hui on a un serveur Mandrake qui fait ça. Mais mandrake sur un serveur, c’est vraiment caca. On vient d’investir dans un 2e serveur, et j’aimerai bien faire ça plus propre.

#15

Haem, tant que je vous ai sous la main…

C’est quoi la philosophie Debian vis à vis du stable/testing ?
Parce que j’ai l’impression que les paquets en stable datent vraiment de Mathusalem.

Et autre chose, si demain Etch passe en stable ? Il se passera quoi pour l’utilisateur comme moi ? Ca va mettre à jour “à la barbare” tous mes paquets ?

#16

Un mainteneur prend les sources (que l’ont appele upstream), il les package.
Il les envoie dans Incoming. Incoming est le point d’entrée de tout rajout (sécurité, repackaging en cas de nouveau upstream, build en binaire).
Le paquet passe en Unstable automatiquement, il devient officiel (et optionnellement aussi il passe en experimental).
Ensuite si il répond à certains critères (Release Critical Bugs, depend de paquets seulement en testing, est installable sur plusieurs architectures, suit la debian policy,…) alors il passe automatiquement en Testing.
S’il repond encore a plus de critère et s’il est assez vieux, il passe dans un etat transitoire Frozen;a ce stade plus aucune fonctionnalité n’est ajoutée. Dès que tous les bugs serieux (severité serious) et RC sont résolus, il passe en Stable.

Le cycle de vie du paquet : les mises à jour arrivent sur Incoming, sont repercutées automatiquement en unstable (puis testing,…) et parfois aussi en experimental. On peut aussi sauter testing et unstable pour faire des mis à jour simples directement vers stable (securité, traduction,…)

Il y aurait encore des détails à rajouter pour avoir un cycle de vie typique.

Quand Etch deviendra stable et remplacera la sarge, il faudra remplacer sarge par etch dans le sources.list suivi d’un apt-get dist-upgrade.

Un bordel structuré en gros :slightly_smiling:

#17

quote="GTS"
Et autre chose, si demain Etch passe en stable ? Il se passera quoi pour l’utilisateur comme moi ? Ca va mettre à jour “à la barbare” tous mes paquets ?[/quote]Ce que voulait dire Boris, c’est qu’il vaut donc mieux utiliser des depots en utilisant sarge que stable, comme ça, tu te moques de savoir si la sarge est stable ou oldstable, tu fais ta migration en ajoutant les sources etch quand tu penses que c’est le moment.

#18

Euh… Dans ma boite j’ai tout un tas de terminaux passifs qui accèdent au dit serveur via Vnc.

Sur le serveur je lance Xvnc en tant que service et tout le monde arrive sur un environnement différent.

Aujourd’hui on a un serveur Mandrake qui fait ça. Mais mandrake sur un serveur, c’est vraiment caca. On vient d’investir dans un 2e serveur, et j’aimerai bien faire ça plus propre.[/quote]

Mais tu utilise aussi ton serveur pour surfer :confused:

Sarge est tres bien pour les serveurs (secu, stabilité…) si tu as besoin de qq paquets spécifique en + récent backport… Mais en station, sarge est un peu vieillo forcement c’est qd meme pas trop fait pour ca…