Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Downgrade par la patience ?

11 réponses
Avatar
Damien TOURDE
Bonjour,

Je suis actuellement en Sid, et si, pour l'instant ça se passe bien, je
ne ressent finalement pas du tout le besoin d'avoir les tous derniers
paquets tout de suite.

En revanche, je ne fais pas les mise-à-jour très fréquemment, ce qui
n'est pas forcément un comportement très sain avec Sid :-)

Et pour la continuité des services que je fais tourner sur ma machine
(principalement des conteneurs dockers pour mon réseau local/usage
privé), je souhaiterais revenir sur (au moins) du testing.



Aussi, j'aimerais repasser à Stretch (et peut-être y attendre sagement
le freeze pour repasser en stable avec la release), mais sans
réinstallation ce serait encore mieux.


Je voulais savoir si en mettant mes sources.list en testing, et en ne
faisant jamais au grand jamais de dist-upgrade, j'avais une change de
repasser en "testing pur", sans perte ni fracas ?


Si vous avez d'autres idées avec plaisir, toujours est-il
qu'aujourd'hui, ma Debian n'a pas de bug pour mon utilisation, donc je
n'ai pas besoin d'un downgrade qui se fait le temps d'une nuit blanche,
mais je me contente très bien d'un downgrade progressif.



Merci par avance,
Damien T

10 réponses

1 2
Avatar
BERTRAND Joël
Damien TOURDE a écrit :
Bonjour,
Je suis actuellement en Sid, et si, pour l'instant ça se passe bien, je
ne ressent finalement pas du tout le besoin d'avoir les tous derniers
paquets tout de suite.
En revanche, je ne fais pas les mise-à-jour très fréquemment, ce qui
n'est pas forcément un comportement très sain avec Sid :-)
Et pour la continuité des services que je fais tourner sur ma machine
(principalement des conteneurs dockers pour mon réseau local/usage
privé), je souhaiterais revenir sur (au moins) du testing.
Aussi, j'aimerais repasser à Stretch (et peut-être y attendre sagement
le freeze pour repasser en stable avec la release), mais sans
réinstallation ce serait encore mieux.
Je voulais savoir si en mettant mes sources.list en testing, et en ne
faisant jamais au grand jamais de dist-upgrade, j'avais une change de
repasser en "testing pur", sans perte ni fracas ?
Si vous avez d'autres idées avec plaisir, toujours est-il
qu'aujourd'hui, ma Debian n'a pas de bug pour mon utilisation, donc je
n'ai pas besoin d'un downgrade qui se fait le temps d'une nuit blanche,
mais je me contente très bien d'un downgrade progressif.
Merci par avance,
Damien T

Bonsoir,
Je ne comprends pas trop le problème. En mettant les dépôts de stable,
testing et unstable avec un pinning sur testing, tu vas passer
progressivement de unstable à testing. Normalement sans douleur.
Cordialement,
JKB
Avatar
Damien TOURDE
Le lundi 22 août 2016 à 22:55 +0200, BERTRAND Joël a écrit :
 
Bonsoir,
Je ne comprends pas trop le problème. En mettant les dépôts de
stable, 
testing et unstable avec un pinning sur testing, tu vas passer 
progressivement de unstable à testing. Normalement sans douleur.
Cordialement,
JKB

Quelle serait la différence entre les 3 dépôts + pinning testing et
simplement n'avoir que des références à testing ?
La peur que j'ai c'est qu'il me downgrade les paquets au lieu de
simplement attendre que testing ait rattrapé ma version de sid (en gros
sid au 20/08/2016).
Car d'après la doc Debian, les scripts d'installation ne sont pas du
tout prévu pour un downgrade des paquets.
Merci,
Damien
Avatar
BERTRAND Joël
Damien TOURDE a écrit :
Le lundi 22 août 2016 à 22:55 +0200, BERTRAND Joël a écrit :
Bonsoir,
Je ne comprends pas trop le problème. En mettant les dépôts de
stable,
testing et unstable avec un pinning sur testing, tu vas passer
progressivement de unstable à testing. Normalement sans douleur.
Cordialement,
JKB

Quelle serait la différence entre les 3 dépôts + pinning testing et
simplement n'avoir que des références à testing ?

J'utilise testing en rolling-release. Je n'ai jamais réussi à faire
avec la seule testing. J'ai donc les trois dépôts (ainsi que volatile et
expérimental) dans mon source avec une préférence pour testing.
La peur que j'ai c'est qu'il me downgrade les paquets au lieu de
simplement attendre que testing ait rattrapé ma version de sid (en gros
sid au 20/08/2016).

Il ne le fera pas. Lorsque tu installes un soft avec apt-get -t
unstable xxx, il reste dans l'état unstable jusqu'à ce que testing ait
rattrapé unstable.
Car d'après la doc Debian, les scripts d'installation ne sont pas du
tout prévu pour un downgrade des paquets.

C'est le moint que l'on puisse dire.
Cordialement,
JKB
Avatar
didier gaumet
Le 23/08/2016 à 00:41, Damien TOURDE a écrit :
[...]
La peur que j'ai c'est qu'il me downgrade les paquets au lieu de
simplement attendre que testing ait rattrapé ma version de sid (en gros
sid au 20/08/2016).

[...]
Comme l'a dit Joël, ça n'arrivera pas, sauf si tu utilises apt-get
(quand j'avais essayé je n'avais jamais réussi un downgrade avec
aptitude) et que tu mets des priorités strictement supérieures à 1000
dans /etc/apt/preferences sur ce ce que tu veux downgrader, avant de
revenir à des priorités normales par la suite
Avatar
Gabriel Philippe
2016-08-22 22:46 GMT+02:00 Damien TOURDE :
Je voulais savoir si en mettant mes sources.list en testing, et en ne
faisant jamais au grand jamais de dist-upgrade, j'avais une change de
repasser en "testing pur", sans perte ni fracas ?

Je dirais que c'est risqué.
Les numéros de version en unstable sont supérieurs à ceux de stable et
testing, et il faudra un certain temps pour que, pour un paquet donné,
la version que tu utilises devienne celle de la variante inférieure.
Mais dans l'intervalle, il peut y avoir des corrections de bugs ou de
sécurité. Dans unstable cela donnera un paquet plus récent ( qui ne
sera pas installé chez toi), et dans une variante inférieure cela peut
donner un paquet avec une petite révision dans le numéro de versi on,
mais toujours avec un numéro inférieur à la version install ée sur ton
ordinateur. Par conséquent, je pense que pour certains paquets tu peux
rester très longtemps avec des bugs et des failles de sécurità © non
corrigés.
Et pourquoi testing? N'est-ce pas le pire des deux mondes? Cela n'a ni
la stabilité de stable, ni la fréquence de mise à jour (et d onc de
corrections des problèmes) d'unstable. A une époque je l'utilisai s,
des bugs gênants apparaissaient parfois et restaient pendant des
mois...
--
Gabriel
Avatar
Gabriel Philippe
2016-08-23 11:06 GMT+02:00 Gabriel Philippe :
Les numéros de version en unstable sont supérieurs à ceux de stable et
testing, et il faudra un certain temps pour que, pour un paquet donnà ©,
la version que tu utilises devienne celle de la variante inférieure.
Mais dans l'intervalle, il peut y avoir des corrections de bugs ou de
sécurité. Dans unstable cela donnera un paquet plus récent (qui ne
sera pas installé chez toi), et dans une variante inférieure ce la peut
donner un paquet avec une petite révision dans le numéro de ver sion,
mais toujours avec un numéro inférieur à la version instal lée sur ton
ordinateur. Par conséquent, je pense que pour certains paquets tu pe ux
rester très longtemps avec des bugs et des failles de sécurit é non
corrigés.

Ca c'est surtout pour le passage de testing ou unstable vers stable.
Pour le cas spécifique de migration vers testing c'est certainement
moins vrai, mais il reste les problèmes propres à testing. Les mi ses à
jour de sécurité n'y sont pas appliquées, il faut que ç a passe d'abord
par unstable. Ce qui veut dire que si un paquet fait l'objet d'une
mise à jour de sécurité, mais qu'il dépend d'une biblio thèque qui elle
voit des mises à jours très fréquentes, trop fréquentes pour qu'elles
aient le temps de passer dans testing, ce paquet et ses dépendances
peut mettre très longtemps avant d'arriver dans testing. Et pendant ce
temps tu subis les problèmes de ton paquet non mis à jour.
https://www.debian.org/doc/manuals/securing-debian-howto/ch10.en.html#s-sec urity-support-testing
Bref, testing c'est pour tester, pas pour utiliser.
--
Gabriel
Avatar
J
Le mardi 23 août 2016 à 11:15 +0200, Gabriel Philippe a écrit :
Bref, testing c'est pour tester, pas pour utiliser.

Les bugs critiques de sécurité sont quand même corrigés assez
rapidement mais pas prioritairement(stable est prioritaire et Sid
bénéficie de son statut d'unstable avec des mises à jour au fur et à
mesure).
Pour les paquets bloqués dans une version ou dans un état non
fonctionnel c'est vrai, et généralement soluble dans le pinning avec
unstable en attendant que ça arrive dans Testing, en sachant que si ça
n'arrive pas c'est à priori parce qu'il y a un problème d'intégration
dans Testing (dépendances pas prêtes...) ou des bugs critiques
rédhibitoires pour l'intégration.
Testing et Unstable sont généralement utilisables... à ses risques et
périls et à condition d'être un peu rôdé à la résolution des problèmes
et à condition de savoir lire les avertissements au moment des mises à
jour.
Avatar
Damien TOURDE
Le mardi 23 août 2016 à 11:06 +0200, Gabriel Philippe a écrit :
 
Et pourquoi testing? N'est-ce pas le pire des deux mondes? Cela n'a
ni
la stabilité de stable, ni la fréquence de mise à jour (et donc de
corrections des problèmes) d'unstable. A une époque je l'utilisais,
des bugs gênants apparaissaient parfois et restaient pendant des
mois...

Testing c'est surtout pour pouvoir passer en stable quand la testing
sera la nouvelle stable.
Il ne le fera pas. Lorsque tu installes un soft avec apt-get -t 
unstable xxx, il reste dans l'état unstable jusqu'à ce que testing
ait rattrapé unstable.

Donc lors d'un apt-get update classique, il ne fera pas de downgrade si
le pinning est bon, mais j'ai un doute sur celui qui serait bon.
Si je fais un pinning prioritaire sur testing par exemple, ne va-t'il
pas remplacer mes paquets par les paquets testing ?
Car d'après mes souvenirs de la doc, le pinning est prioritaire sur le
numéro de version...
Avatar
didier gaumet
Le 23/08/2016 à 18:03, Damien TOURDE a écrit :
[...]
Si je fais un pinning prioritaire sur testing par exemple, ne va-t'il
pas remplacer mes paquets par les paquets testing ?
Car d'après mes souvenirs de la doc, le pinning est prioritaire sur le
numéro de version...

non, pas de souci
man apt_preferences:
[...]
Puis APT applique les règles suivantes pour déterminer la version du
paquet qu'il faut installer (par ordre de priorité) :
· Ne jamais revenir en arrière, sauf si la priorité d'une version
disponible dépasse 1000. « Revenir en arrière » signifie installer une
version moins récente que la version installée. Il faut noter qu'aucune
des priorités par défaut n'excède 1000 ; de telles valeurs ne peuvent
être définies que dans le fichier des préférences. Notez aussi qu'il est
risqué de revenir en arrière.
[...]
Avatar
Damien TOURDE
Merci pour le passage du man qui m'avait échappé.
Je vais faire un pinning < 1000 pour testing et quand testing sera la
nouvelle stable, y rester.
Et puis si on ne me voit pas sur la liste, je serais peut-être en train
de tout réinstaller en pleurant :^)
Le mardi 23 août 2016 à 20:12 +0200, didier gaumet a écrit :
Le 23/08/2016 à 18:03, Damien TOURDE a écrit :
[...]
Si je fais un pinning prioritaire sur testing par exemple, ne va-
t'il
pas remplacer mes paquets par les paquets testing ?
Car d'après mes souvenirs de la doc, le pinning est prioritaire sur
le
numéro de version...

non, pas de souci
man apt_preferences:
[...]
Puis APT applique les règles suivantes pour déterminer la version du
paquet qu'il faut installer (par ordre de priorité) :
· Ne jamais revenir en arrière, sauf si la priorité d'une version
disponible dépasse 1000. « Revenir en arrière » signifie installer
une
version moins récente que la version installée. Il faut noter
qu'aucune
des priorités par défaut n'excède 1000 ; de telles valeurs ne peuvent
être définies que dans le fichier des préférences. Notez aussi qu'il
est
risqué de revenir en arrière.
[...]
1 2