J'aimerais savoir s'il est judicieux de passer de lenny nouvellement
stable à squeeze de façon à profité des mises à jours de paquets.
Est-ce qu'il y a des risques potentiellement importants ? Pour ma part,
il s'agit d'un serveur qui n'utilise pas de serveur graphique xorg (il
me semble que c'est surtout au niveau de xorg qu'il y a souvent quelques
problèmes).
Si c'est possible, la méthode est de changer les sources dans
sources.list
J'aimerais savoir s'il est judicieux de passer de lenny nouvellement
stable à squeeze de façon à profité des mises à jours de paquets.
Est-ce qu'il y a des risques potentiellement importants ? Pour ma part,
il s'agit d'un serveur qui n'utilise pas de serveur graphique xorg (il
me semble que c'est surtout au niveau de xorg qu'il y a souvent quelques
problèmes).
Si c'est possible, la méthode est de changer les sources dans
sources.list
J'aimerais savoir s'il est judicieux de passer de lenny nouvellement
stable à squeeze de façon à profité des mises à jours de paquets.
Est-ce qu'il y a des risques potentiellement importants ? Pour ma part,
il s'agit d'un serveur qui n'utilise pas de serveur graphique xorg (il
me semble que c'est surtout au niveau de xorg qu'il y a souvent quelques
problèmes).
Si c'est possible, la méthode est de changer les sources dans
sources.list
Ça dépend de l'utilisation. Si tu étais déjà en Lenny avant,
c'est équivalent à passer à la prochaine maintenant: tu
n'es jamais en stable.
Il y a toujours des risques à toute mise à jour, si le
serveur est important il faut toujours déployer la mise à
jour sur un serveur de test (c'est aussi valable pour le
passage de stable n à stable n+1)
Ça dépend de l'utilisation. Si tu étais déjà en Lenny avant,
c'est équivalent à passer à la prochaine maintenant: tu
n'es jamais en stable.
Il y a toujours des risques à toute mise à jour, si le
serveur est important il faut toujours déployer la mise à
jour sur un serveur de test (c'est aussi valable pour le
passage de stable n à stable n+1)
Ça dépend de l'utilisation. Si tu étais déjà en Lenny avant,
c'est équivalent à passer à la prochaine maintenant: tu
n'es jamais en stable.
Il y a toujours des risques à toute mise à jour, si le
serveur est important il faut toujours déployer la mise à
jour sur un serveur de test (c'est aussi valable pour le
passage de stable n à stable n+1)
Yves Rutschle a écrit :
> Ça dépend de l'utilisation. Si tu étais déjà en Lenny avant,
> c'est équivalent à passer à la prochaine maintenant: tu
> n'es jamais en stable.
Oui, c'était une installation de Lenny depuis environ 6 mois.
> Il y a toujours des risques à toute mise à jour, si le
> serveur est important il faut toujours déployer la mise à
> jour sur un serveur de test (c'est aussi valable pour le
> passage de stable n à stable n+1)
Ce n'est pas vraiment sensible, seulement je ne peux pas me permettre de
casser l'installation car le système est entièrement chiffré, je ri sque
d'avoir un certain nombre de difficultés de réinstaller le système tout
en conservant les données sur les disques.
En fait, je me demandais surtout si les paquets actuellement sur squeeze
était très différents de ceux présents dans les dépôts de Len ny (grosse
disparité de versions ou mise à jours progressives).
Yves Rutschle a écrit :
> Ça dépend de l'utilisation. Si tu étais déjà en Lenny avant,
> c'est équivalent à passer à la prochaine maintenant: tu
> n'es jamais en stable.
Oui, c'était une installation de Lenny depuis environ 6 mois.
> Il y a toujours des risques à toute mise à jour, si le
> serveur est important il faut toujours déployer la mise à
> jour sur un serveur de test (c'est aussi valable pour le
> passage de stable n à stable n+1)
Ce n'est pas vraiment sensible, seulement je ne peux pas me permettre de
casser l'installation car le système est entièrement chiffré, je ri sque
d'avoir un certain nombre de difficultés de réinstaller le système tout
en conservant les données sur les disques.
En fait, je me demandais surtout si les paquets actuellement sur squeeze
était très différents de ceux présents dans les dépôts de Len ny (grosse
disparité de versions ou mise à jours progressives).
Yves Rutschle a écrit :
> Ça dépend de l'utilisation. Si tu étais déjà en Lenny avant,
> c'est équivalent à passer à la prochaine maintenant: tu
> n'es jamais en stable.
Oui, c'était une installation de Lenny depuis environ 6 mois.
> Il y a toujours des risques à toute mise à jour, si le
> serveur est important il faut toujours déployer la mise à
> jour sur un serveur de test (c'est aussi valable pour le
> passage de stable n à stable n+1)
Ce n'est pas vraiment sensible, seulement je ne peux pas me permettre de
casser l'installation car le système est entièrement chiffré, je ri sque
d'avoir un certain nombre de difficultés de réinstaller le système tout
en conservant les données sur les disques.
En fait, je me demandais surtout si les paquets actuellement sur squeeze
était très différents de ceux présents dans les dépôts de Len ny (grosse
disparité de versions ou mise à jours progressives).
Bonjour,
sur une machine critique, aucun interet de passer en squeeze, ça va être
pendant minimum un an la pire des trois solutions entre lenny, squeeze, et
sid. Les paquets arrivant seront dans un état de compatibilité entre eux
absolument non testés en plus du fait que la sécurité de chaque paquet n'est
pas garantie, et les versions vont commencer à se succèder à rythme rapide en
squeeze dans ce contexte instable. Ceci contrairement à la sid qui évolue
sans à coup (un petit peu de mouvements avec la sortie de lenny, mais le
dist-upgrade s'est fait sans incident pour moi) et malgré l'absence d'équipe
sécurité et de menus défauts, reste plus stable que nombre de distribs
annoncées comme des produits finalisés.
Pour l'instant, donc, la squeeze va être destinée surtout aux bénévoles prets
à se prendre les pires bugs en pleine face.
Si tu veux des logiciels "cutting edge" prends une sid. Si tu ne veux pas
prendre de risque, restes en Lenny. La squeeze, c'est pour rendre service aux
autres en remontant les bugs.
++, MATT
Bonjour,
sur une machine critique, aucun interet de passer en squeeze, ça va être
pendant minimum un an la pire des trois solutions entre lenny, squeeze, et
sid. Les paquets arrivant seront dans un état de compatibilité entre eux
absolument non testés en plus du fait que la sécurité de chaque paquet n'est
pas garantie, et les versions vont commencer à se succèder à rythme rapide en
squeeze dans ce contexte instable. Ceci contrairement à la sid qui évolue
sans à coup (un petit peu de mouvements avec la sortie de lenny, mais le
dist-upgrade s'est fait sans incident pour moi) et malgré l'absence d'équipe
sécurité et de menus défauts, reste plus stable que nombre de distribs
annoncées comme des produits finalisés.
Pour l'instant, donc, la squeeze va être destinée surtout aux bénévoles prets
à se prendre les pires bugs en pleine face.
Si tu veux des logiciels "cutting edge" prends une sid. Si tu ne veux pas
prendre de risque, restes en Lenny. La squeeze, c'est pour rendre service aux
autres en remontant les bugs.
++, MATT
Bonjour,
sur une machine critique, aucun interet de passer en squeeze, ça va être
pendant minimum un an la pire des trois solutions entre lenny, squeeze, et
sid. Les paquets arrivant seront dans un état de compatibilité entre eux
absolument non testés en plus du fait que la sécurité de chaque paquet n'est
pas garantie, et les versions vont commencer à se succèder à rythme rapide en
squeeze dans ce contexte instable. Ceci contrairement à la sid qui évolue
sans à coup (un petit peu de mouvements avec la sortie de lenny, mais le
dist-upgrade s'est fait sans incident pour moi) et malgré l'absence d'équipe
sécurité et de menus défauts, reste plus stable que nombre de distribs
annoncées comme des produits finalisés.
Pour l'instant, donc, la squeeze va être destinée surtout aux bénévoles prets
à se prendre les pires bugs en pleine face.
Si tu veux des logiciels "cutting edge" prends une sid. Si tu ne veux pas
prendre de risque, restes en Lenny. La squeeze, c'est pour rendre service aux
autres en remontant les bugs.
++, MATT
Mathieu JANIN a écrit :
> Bonjour,
> sur une machine critique, aucun interet de passer en squeeze, ça va être
> pendant minimum un an la pire des trois solutions entre lenny, squeeze,
> et sid. Les paquets arrivant seront dans un état de compatibilité e ntre
> eux absolument non testés en plus du fait que la sécurité de chaq ue
> paquet n'est pas garantie, et les versions vont commencer à se succ èder à
> rythme rapide en squeeze dans ce contexte instable. Ceci contrairement à
> la sid qui évolue sans à coup (un petit peu de mouvements avec la sortie
> de lenny, mais le dist-upgrade s'est fait sans incident pour moi) et
> malgré l'absence d'équipe sécurité et de menus défauts, reste plus stable
> que nombre de distribs annoncées comme des produits finalisés.
> Pour l'instant, donc, la squeeze va être destinée surtout aux bén évoles
> prets à se prendre les pires bugs en pleine face.
> Si tu veux des logiciels "cutting edge" prends une sid. Si tu ne veux
> pas prendre de risque, restes en Lenny. La squeeze, c'est pour rendre
> service aux autres en remontant les bugs.
>
> ++, MATT
C'est surprenant que squeeze soit plus "dangereux" que sid, car selon ce
que l'on peut lire sur le site de debian, les paquets arrivant sur
squeeze doivent d'abord passer par sid pendant un certain temps.
Il semble que la mise des paquets depuis sid dans la testing soit fait
automatiquement d'ailleurs.
Mathieu JANIN a écrit :
> Bonjour,
> sur une machine critique, aucun interet de passer en squeeze, ça va être
> pendant minimum un an la pire des trois solutions entre lenny, squeeze,
> et sid. Les paquets arrivant seront dans un état de compatibilité e ntre
> eux absolument non testés en plus du fait que la sécurité de chaq ue
> paquet n'est pas garantie, et les versions vont commencer à se succ èder à
> rythme rapide en squeeze dans ce contexte instable. Ceci contrairement à
> la sid qui évolue sans à coup (un petit peu de mouvements avec la sortie
> de lenny, mais le dist-upgrade s'est fait sans incident pour moi) et
> malgré l'absence d'équipe sécurité et de menus défauts, reste plus stable
> que nombre de distribs annoncées comme des produits finalisés.
> Pour l'instant, donc, la squeeze va être destinée surtout aux bén évoles
> prets à se prendre les pires bugs en pleine face.
> Si tu veux des logiciels "cutting edge" prends une sid. Si tu ne veux
> pas prendre de risque, restes en Lenny. La squeeze, c'est pour rendre
> service aux autres en remontant les bugs.
>
> ++, MATT
C'est surprenant que squeeze soit plus "dangereux" que sid, car selon ce
que l'on peut lire sur le site de debian, les paquets arrivant sur
squeeze doivent d'abord passer par sid pendant un certain temps.
Il semble que la mise des paquets depuis sid dans la testing soit fait
automatiquement d'ailleurs.
Mathieu JANIN a écrit :
> Bonjour,
> sur une machine critique, aucun interet de passer en squeeze, ça va être
> pendant minimum un an la pire des trois solutions entre lenny, squeeze,
> et sid. Les paquets arrivant seront dans un état de compatibilité e ntre
> eux absolument non testés en plus du fait que la sécurité de chaq ue
> paquet n'est pas garantie, et les versions vont commencer à se succ èder à
> rythme rapide en squeeze dans ce contexte instable. Ceci contrairement à
> la sid qui évolue sans à coup (un petit peu de mouvements avec la sortie
> de lenny, mais le dist-upgrade s'est fait sans incident pour moi) et
> malgré l'absence d'équipe sécurité et de menus défauts, reste plus stable
> que nombre de distribs annoncées comme des produits finalisés.
> Pour l'instant, donc, la squeeze va être destinée surtout aux bén évoles
> prets à se prendre les pires bugs en pleine face.
> Si tu veux des logiciels "cutting edge" prends une sid. Si tu ne veux
> pas prendre de risque, restes en Lenny. La squeeze, c'est pour rendre
> service aux autres en remontant les bugs.
>
> ++, MATT
C'est surprenant que squeeze soit plus "dangereux" que sid, car selon ce
que l'on peut lire sur le site de debian, les paquets arrivant sur
squeeze doivent d'abord passer par sid pendant un certain temps.
Il semble que la mise des paquets depuis sid dans la testing soit fait
automatiquement d'ailleurs.
Mathieu JANIN a écrit :
> Bonjour,
> sur une machine critique, aucun interet de passer en squeeze, ça va être
> pendant minimum un an la pire des trois solutions entre lenny, squeeze,
> et sid. Les paquets arrivant seront dans un état de compatibilité e ntre
> eux absolument non testés en plus du fait que la sécurité de chaq ue
> paquet n'est pas garantie, et les versions vont commencer à se succ èder à
> rythme rapide en squeeze dans ce contexte instable. Ceci contrairement à
> la sid qui évolue sans à coup (un petit peu de mouvements avec la sortie
> de lenny, mais le dist-upgrade s'est fait sans incident pour moi) et
> malgré l'absence d'équipe sécurité et de menus défauts, reste plus stable
> que nombre de distribs annoncées comme des produits finalisés.
> Pour l'instant, donc, la squeeze va être destinée surtout aux bén évoles
> prets à se prendre les pires bugs en pleine face.
> Si tu veux des logiciels "cutting edge" prends une sid. Si tu ne veux
> pas prendre de risque, restes en Lenny. La squeeze, c'est pour rendre
> service aux autres en remontant les bugs.
>
> ++, MATT
C'est surprenant que squeeze soit plus "dangereux" que sid, car selon ce
que l'on peut lire sur le site de debian, les paquets arrivant sur
squeeze doivent d'abord passer par sid pendant un certain temps.
Il semble que la mise des paquets depuis sid dans la testing soit fait
automatiquement d'ailleurs.
Mathieu JANIN a écrit :
> Bonjour,
> sur une machine critique, aucun interet de passer en squeeze, ça va être
> pendant minimum un an la pire des trois solutions entre lenny, squeeze,
> et sid. Les paquets arrivant seront dans un état de compatibilité e ntre
> eux absolument non testés en plus du fait que la sécurité de chaq ue
> paquet n'est pas garantie, et les versions vont commencer à se succ èder à
> rythme rapide en squeeze dans ce contexte instable. Ceci contrairement à
> la sid qui évolue sans à coup (un petit peu de mouvements avec la sortie
> de lenny, mais le dist-upgrade s'est fait sans incident pour moi) et
> malgré l'absence d'équipe sécurité et de menus défauts, reste plus stable
> que nombre de distribs annoncées comme des produits finalisés.
> Pour l'instant, donc, la squeeze va être destinée surtout aux bén évoles
> prets à se prendre les pires bugs en pleine face.
> Si tu veux des logiciels "cutting edge" prends une sid. Si tu ne veux
> pas prendre de risque, restes en Lenny. La squeeze, c'est pour rendre
> service aux autres en remontant les bugs.
>
> ++, MATT
C'est surprenant que squeeze soit plus "dangereux" que sid, car selon ce
que l'on peut lire sur le site de debian, les paquets arrivant sur
squeeze doivent d'abord passer par sid pendant un certain temps.
Il semble que la mise des paquets depuis sid dans la testing soit fait
automatiquement d'ailleurs.
Mathieu JANIN a écrit :
> Bonjour,
> sur une machine critique, aucun interet de passer en squeeze, ça va être
> pendant minimum un an la pire des trois solutions entre lenny, squeeze,
> et sid. Les paquets arrivant seront dans un état de compatibilité e ntre
> eux absolument non testés en plus du fait que la sécurité de chaq ue
> paquet n'est pas garantie, et les versions vont commencer à se succ èder à
> rythme rapide en squeeze dans ce contexte instable. Ceci contrairement à
> la sid qui évolue sans à coup (un petit peu de mouvements avec la sortie
> de lenny, mais le dist-upgrade s'est fait sans incident pour moi) et
> malgré l'absence d'équipe sécurité et de menus défauts, reste plus stable
> que nombre de distribs annoncées comme des produits finalisés.
> Pour l'instant, donc, la squeeze va être destinée surtout aux bén évoles
> prets à se prendre les pires bugs en pleine face.
> Si tu veux des logiciels "cutting edge" prends une sid. Si tu ne veux
> pas prendre de risque, restes en Lenny. La squeeze, c'est pour rendre
> service aux autres en remontant les bugs.
>
> ++, MATT
C'est surprenant que squeeze soit plus "dangereux" que sid, car selon ce
que l'on peut lire sur le site de debian, les paquets arrivant sur
squeeze doivent d'abord passer par sid pendant un certain temps.
Il semble que la mise des paquets depuis sid dans la testing soit fait
automatiquement d'ailleurs.
Tu mettrais en doute ma bonne parole mécréant ?
Lis sur mes lèvres.
;)
.>Chaque< paquet dans testing est une version plus stable dans l'absolu qu'un
paquet de sid, oui, mais juste aprés le lancement d'une nouvelle testing, les
paquets de sid >entre eux< sont plus bien plus compatibles que ceux de la
testing >entre eux< au niveau de version ou ils en sont, car pour débuguer
les problêmes >à l'intérieur des paquets< en sid, les développeurs ont
tendance à lisser d'abord les bugs les plus dramatiques avec les paquets
corrèlés, pour pouvoir bosser tranquillement sur les problêmes qui concernent
la sid (l'intérieur des paquets). Du coup, une testing est >globalement< bien
plus buguée à son début que la sid (la sid restant presque toujours
parfaitement exploitable pour une machine perso).
Avec l'approche de la stabilisation de la testing et le ralentissement de
l'importation de nouvelles versions, la situation s'inverse, jusqu'au freeze,
ou le débuguage >d'interaction entre les paquets< arrive à sont sommet... Et
c'est la release, mais c'est la dernière étape.
Enfin généralement, et d'un point de vue totalement personnel et subjectif,
parceque je l'ai vécu plusieurs fois, et parceque c'est la seule explication
qui me permette d'expliquer le quasi monopole de gueulantes concernant la
testing sur les forums juste aprés la release d'une nouvelle stable.
C'est pas du bronze, juste un constat.
C'est mieux comme explication ?
Tu mettrais en doute ma bonne parole mécréant ?
Lis sur mes lèvres.
;)
.>Chaque< paquet dans testing est une version plus stable dans l'absolu qu'un
paquet de sid, oui, mais juste aprés le lancement d'une nouvelle testing, les
paquets de sid >entre eux< sont plus bien plus compatibles que ceux de la
testing >entre eux< au niveau de version ou ils en sont, car pour débuguer
les problêmes >à l'intérieur des paquets< en sid, les développeurs ont
tendance à lisser d'abord les bugs les plus dramatiques avec les paquets
corrèlés, pour pouvoir bosser tranquillement sur les problêmes qui concernent
la sid (l'intérieur des paquets). Du coup, une testing est >globalement< bien
plus buguée à son début que la sid (la sid restant presque toujours
parfaitement exploitable pour une machine perso).
Avec l'approche de la stabilisation de la testing et le ralentissement de
l'importation de nouvelles versions, la situation s'inverse, jusqu'au freeze,
ou le débuguage >d'interaction entre les paquets< arrive à sont sommet... Et
c'est la release, mais c'est la dernière étape.
Enfin généralement, et d'un point de vue totalement personnel et subjectif,
parceque je l'ai vécu plusieurs fois, et parceque c'est la seule explication
qui me permette d'expliquer le quasi monopole de gueulantes concernant la
testing sur les forums juste aprés la release d'une nouvelle stable.
C'est pas du bronze, juste un constat.
C'est mieux comme explication ?
Tu mettrais en doute ma bonne parole mécréant ?
Lis sur mes lèvres.
;)
.>Chaque< paquet dans testing est une version plus stable dans l'absolu qu'un
paquet de sid, oui, mais juste aprés le lancement d'une nouvelle testing, les
paquets de sid >entre eux< sont plus bien plus compatibles que ceux de la
testing >entre eux< au niveau de version ou ils en sont, car pour débuguer
les problêmes >à l'intérieur des paquets< en sid, les développeurs ont
tendance à lisser d'abord les bugs les plus dramatiques avec les paquets
corrèlés, pour pouvoir bosser tranquillement sur les problêmes qui concernent
la sid (l'intérieur des paquets). Du coup, une testing est >globalement< bien
plus buguée à son début que la sid (la sid restant presque toujours
parfaitement exploitable pour une machine perso).
Avec l'approche de la stabilisation de la testing et le ralentissement de
l'importation de nouvelles versions, la situation s'inverse, jusqu'au freeze,
ou le débuguage >d'interaction entre les paquets< arrive à sont sommet... Et
c'est la release, mais c'est la dernière étape.
Enfin généralement, et d'un point de vue totalement personnel et subjectif,
parceque je l'ai vécu plusieurs fois, et parceque c'est la seule explication
qui me permette d'expliquer le quasi monopole de gueulantes concernant la
testing sur les forums juste aprés la release d'une nouvelle stable.
C'est pas du bronze, juste un constat.
C'est mieux comme explication ?
> Goldy a écrit :
C'est tout à fait clair, je comprends mieux maintenant. Merci à Gilles
aussi.
Je vais finalement rester en stable, il s'avère que pour l'utilisation
que j'en fais, je n'ai pas particulièrement besoin d'avoir des versions
de logiciels à jours.
C'est juste qu'à l'époque, j'avais choisie lenny dans l'espoir de
continuer en testing une fois que lenny serait stable (on m'avait
affirmé que c'était possible à l'époque). Mais au final, pour un serveur
de fichier ce n'est pas particulièrement utile.
> Goldy a écrit :
C'est tout à fait clair, je comprends mieux maintenant. Merci à Gilles
aussi.
Je vais finalement rester en stable, il s'avère que pour l'utilisation
que j'en fais, je n'ai pas particulièrement besoin d'avoir des versions
de logiciels à jours.
C'est juste qu'à l'époque, j'avais choisie lenny dans l'espoir de
continuer en testing une fois que lenny serait stable (on m'avait
affirmé que c'était possible à l'époque). Mais au final, pour un serveur
de fichier ce n'est pas particulièrement utile.
> Goldy a écrit :
C'est tout à fait clair, je comprends mieux maintenant. Merci à Gilles
aussi.
Je vais finalement rester en stable, il s'avère que pour l'utilisation
que j'en fais, je n'ai pas particulièrement besoin d'avoir des versions
de logiciels à jours.
C'est juste qu'à l'époque, j'avais choisie lenny dans l'espoir de
continuer en testing une fois que lenny serait stable (on m'avait
affirmé que c'était possible à l'époque). Mais au final, pour un serveur
de fichier ce n'est pas particulièrement utile.
Ce message de Debian-security va dans le même sens, passer en Testing
est une bonne idée (si on en a besoin/envie seulement !) dans sa phase
de consolidation. Pour l'instant c'est plutôt la phase fourre-tout...
http://lists.debian.org/debian-testing-security-announce/2008/12/msg00019.html
Cela dit sur mon post perso "desktop" je suis en Squeeze, et rien ne
fume encore... Jusque là !
Ce message de Debian-security va dans le même sens, passer en Testing
est une bonne idée (si on en a besoin/envie seulement !) dans sa phase
de consolidation. Pour l'instant c'est plutôt la phase fourre-tout...
http://lists.debian.org/debian-testing-security-announce/2008/12/msg00019.html
Cela dit sur mon post perso "desktop" je suis en Squeeze, et rien ne
fume encore... Jusque là !
Ce message de Debian-security va dans le même sens, passer en Testing
est une bonne idée (si on en a besoin/envie seulement !) dans sa phase
de consolidation. Pour l'instant c'est plutôt la phase fourre-tout...
http://lists.debian.org/debian-testing-security-announce/2008/12/msg00019.html
Cela dit sur mon post perso "desktop" je suis en Squeeze, et rien ne
fume encore... Jusque là !
Bonjour,
Le jeudi 19 février 2009, thveillon.debian a écrit...Ce message de Debian-security va dans le même sens, passer en Testing
est une bonne idée (si on en a besoin/envie seulement !) dans sa phase
de consolidation. Pour l'instant c'est plutôt la phase fourre-tout...http://lists.debian.org/debian-testing-security-announce/2008/12/msg00019.htmlCela dit sur mon post perso "desktop" je suis en Squeeze, et rien ne
fume encore... Jusque là !
Bizarre, ce fil, je trouve. Je suis en testing depuis que Woody y est
passée, ce n'est pas si vieux, certes, mais ça fait quelques
versions déjà. Nous avons 3 machines en testing à la maison. Je
n'ai jamais remarqué de problème particulier sur les mises à jour de
testing juste après la sortie de la dernière version stable. Serais je
chanceux ? D'une manière générale, les problèmes sur les mises à jour
depuis la Woody, en testing, doivent se compter, chez moi, sur les
doigts d'une main. Ce qui fait, je trouve, une remarquable stabilité.
Bonjour,
Le jeudi 19 février 2009, thveillon.debian a écrit...
Ce message de Debian-security va dans le même sens, passer en Testing
est une bonne idée (si on en a besoin/envie seulement !) dans sa phase
de consolidation. Pour l'instant c'est plutôt la phase fourre-tout...
http://lists.debian.org/debian-testing-security-announce/2008/12/msg00019.html
Cela dit sur mon post perso "desktop" je suis en Squeeze, et rien ne
fume encore... Jusque là !
Bizarre, ce fil, je trouve. Je suis en testing depuis que Woody y est
passée, ce n'est pas si vieux, certes, mais ça fait quelques
versions déjà. Nous avons 3 machines en testing à la maison. Je
n'ai jamais remarqué de problème particulier sur les mises à jour de
testing juste après la sortie de la dernière version stable. Serais je
chanceux ? D'une manière générale, les problèmes sur les mises à jour
depuis la Woody, en testing, doivent se compter, chez moi, sur les
doigts d'une main. Ce qui fait, je trouve, une remarquable stabilité.
Bonjour,
Le jeudi 19 février 2009, thveillon.debian a écrit...Ce message de Debian-security va dans le même sens, passer en Testing
est une bonne idée (si on en a besoin/envie seulement !) dans sa phase
de consolidation. Pour l'instant c'est plutôt la phase fourre-tout...http://lists.debian.org/debian-testing-security-announce/2008/12/msg00019.htmlCela dit sur mon post perso "desktop" je suis en Squeeze, et rien ne
fume encore... Jusque là !
Bizarre, ce fil, je trouve. Je suis en testing depuis que Woody y est
passée, ce n'est pas si vieux, certes, mais ça fait quelques
versions déjà. Nous avons 3 machines en testing à la maison. Je
n'ai jamais remarqué de problème particulier sur les mises à jour de
testing juste après la sortie de la dernière version stable. Serais je
chanceux ? D'une manière générale, les problèmes sur les mises à jour
depuis la Woody, en testing, doivent se compter, chez moi, sur les
doigts d'une main. Ce qui fait, je trouve, une remarquable stabilité.