Vous n'êtes pas identifié(e).
Dernière modification par Frosch (21-01-2016 17:49:12)
Hors ligne
Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.
En ligne
Dernière modification par anonyme (16-12-2015 21:35:41)
Dernière modification par nono47 (17-12-2015 23:03:32)
Hors ligne
Dernière modification par misaine (19-12-2015 19:37:10)
amd phenom 7650 , 4 Go DDR2 ,GeForce N210
Hors ligne
Hors ligne
Je vois que j'ai le choix entre la publication officielle «alpha 5», un instantané hebdomadaire et un instantané journalier. Il y est dit que la version recommandée est la alpha 5 officielle. Vous confirmez ?
oui et l'hedomadaire, le journalier ne permet pas d'etre sur a 100% de l'integralité.
Pense a mettre les ligne nonfree si besoin et contrib, voir la doc, mais sinon j'ai un sources.list tout propre que j'utilise sur sid et sur stable(suffit de (de)commenter les lignes qui sont chez moi assez clair(j'ai mis des commentaires).
avec apt-get tu a l options -s pour faire une simulation (sur un upgrade) , beaucoup utilise aussi aptitude (avec l option -s aussi )
aptitude est encore vivant ou pas, car quand je passe en sid, aptitude degage, alors je me dis que debian prefere apt? Qu'en est il?
Pourquoi conseiller une ligne de testing? C'est plutot si tu veux etre en testing qu'il faut une ligne de sid et un fichier preference, car sid est toujours complete alors que testing non. Apres je suis peut etre dans l'erreur, mais ça ferait alors un moment que je suis dans l'erreur
https://debian-facile.org/doc:systeme:a … hes-debian
https://www.debian.org/doc/manuals/debi … .html#s3.1
sinon suivre bien les bugs de listbugs, attendre une certaine durée pour appliquer les mises a jour, comme ça de nouveau bugs seront reparer ou detecté.
1 mise a jour par semaine est correcte, tout les jours ça sert a rien. Tu peux te laisser 24 a 48 heures avant de charger les mises a jour, comme ça t'as plus de chance de passer entre les bugs non detecté.
C'est pas bete aussi d'avoir soit une autre version (stable debian) ou une autre distribution sur le pc ou bien sur un autre pc, sinon comme toute distribution tres a la pointe il y a un risque de se trouver en panne pendant une courte durée. Bon je me suis jamais trouvé en panne mais ça peut arriver. Bon j'ai aussi plusieur pc donc si panne il doit avoir, les autre pc pourront m'aider a me dépanner.
Dernière modification par seb95deMLO (21-01-2016 17:32:38)
Au fait, y a-t-il un quelconque intérêt à migrer depuis stable plutôt que depuis testing ?
anonyme t'as repondu tres justement:
Non aucun , a part des ennuies . smile
En faite de stable a sid c'est faisable je le fais fréquemment mais t'auras plus de mise a jour a faire que si tu passais par une testing. Avec stable je suis a plus de 1200 mise a jour si je devais passer a sid, alors que testing tu en auras beaucoup moins et puis ça sera sur des version moins grande donc moins de casse.
Dernière modification par seb95deMLO (21-01-2016 17:36:20)
Hello, je vais donc installer une sid en partant de testing. Seulement, comme si ce n'était pas assez compliqué de trouver la page de téléchargement de testing parmi le fouillis du site de Debian, il faut encore trouver la bonne ISO sur cette page
Je vois que j'ai le choix entre la publication officielle «alpha 5», un instantané hebdomadaire et un instantané journalier. Il y est dit que la version recommandée est la alpha 5 officielle. Vous confirmez ?
oui j utilise encore l "alpha4 " mais tu prend la derniere donc l'alpha5 , et c'est vrai que bien compliqué cette page , pour savoir que choisir ....
il y a le mini install , le cd1 et le dvd1 au choix
ps: comme méthode tu a l install minimale de stretch ( sans bureau ) , modification du sources.list ajout de la ligne sid (vérification des lignes stretch ) ;
upgrade puis installation du bureau.
tu gagne un peu sur le nombres de paquet à mettre a jour et tu maitrise mieux ce que tu veut installer.
si la ligne de commande ne te fait pas peur
@seb95deMLO
non c'est sid qui a des paquets volatiles , mais bon pour contrarier personne il est conseillé dans le cas de sid de faire référence a stretch pour compléter les paquets absent de sid
comme je l ai dit sid sera prioritaire (version superieure) sinon apt-get piochera dans stretch en cas d absence d un paquet.
si on y réfléchit , la référence a stretch dans le sources.list n est pas grave puisque sid est le chef mais le cas ou il y a stretch
ps: je sais pas si exact mais la premiere ligne du sources.list a priorité sur la seconde etc ............ bon j avoue ne pas faire cas de ceci , en general j ajoute la ligne de sid a la fin du fichier et roule ma poule
@++
Dernière modification par anonyme (21-01-2016 18:03:47)
Hors ligne
non c'est sid qui a des paquets volatiles , mais bon pour contrarier personne il est conseillé dans le cas de sid de faire référence a stretch pour compléter les paquets absent de sid
Bah alors debian-facile est dans le faux, et je suis totalement dans le faux, car d'apres mes livres c'est testing qui a des paquets qui disparaient ou qui ne migrent pas d'un coup.Ensuite pour la securité testing est un trou beant, puisque les patchs arrivent dans unstable et attendent d'etre confirmé pour etre testing, et par exemple sur la faille actuelle du kernel, a ce jour, stable et unstable sont bon et testing est encore dans l'attente de correction.
linux (PTS) wheezy 3.2.68-1+deb7u3 fixed
wheezy (security) 3.2.73-2+deb7u2 linux (PTS) wheezy 3.2.68-1+deb7u3 fixed
wheezy (security) 3.2.73-2+deb7u2 fixed
jessie 3.16.7-ckt11-1+deb8u3 vulnerable
jessie (security) 3.16.7-ckt20-1+deb8u3 fixed
stretch 4.3.3-5 vulnerable
sid 4.3.3-7 fixed
linux-2.6 (PTS) squeeze, squeeze (security) 2.6.32-48squeeze6 fixed
squeeze (lts) 2.6.32-48squeeze18 fixedfixed
jessie 3.16.7-ckt11-1+deb8u3 vulnerable
jessie (security) 3.16.7-ckt20-1+deb8u3 fixed
stretch 4.3.3-5 vulnerable
sid 4.3.3-7 fixed
linux-2.6 (PTS) squeeze, squeeze (security) 2.6.32-48squeeze6 fixed
squeeze (lts) 2.6.32-48squeeze18 fixed
Dernière modification par seb95deMLO (21-01-2016 19:55:49)
Mais pour en revenir a sid , faire référence a stretch n'a pas de coté négatif bien au contraire et je pense que sur ce point D_F est d'accord.
Comme tu le dis, DF (et le projet Debian d'ailleurs )recommande l'utilisation de Stable.
Avoir les sources de Testing dans une sid permet de rétrograder un paquet s'il pose problème en Sid mais pas en Testing par exemple. Ça m'est arrivé une ou 2 fois
Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.
En ligne
Mais pour en revenir a sid , faire référence a stretch n'a pas de coté négatif bien au contraire et je pense que sur ce point D_F est d'accord.
Certainement mais dans ce cas tu es obligé de passer par
Perso je roule avec un sources.list pure sid, je decommente les ligne de testing mais a l'occasion je ferais avec les ligne de testing apres tout comme tu le dis ça dois pas faire de mal.
Apres tu as raison pour stable, debian recommande que celle ci et elle est la seule a avoir un suivi(un service "apres vente").