[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Passage de lenny à squeeze



Re,

Pour rentrer un peu dans le vif du sujet ... désolé j'attache beaucoup d'important à l'utilisateur lambda. En fait autant qu'à utilisateur des outils 
bas niveaux.

> « utilisateur final » voulait dire quelque chose : l’utilisateur
> n’a pas à réaliser cette manip., c’est l’administrateur qui la
> fera.

Ok, en partant du principe qu'on travail sur une distribution jouant le rôle de serveur, ma question ne se pose pas, c'est hors sujet. Je suis 
d'accord.

En se positionnant sur un point de vue desktop/laptop ou autre, il existe des outils déjà adaptés pour réaliser ce genre d'upgrade. Je pense notament 
à update-manager et update-notifier. Je ne les utilise pas, mais je crois me souvenir que ce genre d'outil oriente bien l'utilisateur final. 
Peuvent-ils demander un premier reboot après une première session de mise à jour (le noyau dans notre cas), puis continuer la suite des séquences 
d'upgrade ? Pour faire l'analogie avec un certain OS conça à Redmond, j'ai déjà vu ce genre de mise à jour nécessitant un redémarrage après un 
premier lot d'update. Nos amis de Canonical le gère aussi je crois.

> Je vois mal comment éviter de rebouter sur le nouveau 
> noyau avant de continuer. La procédure de mise à jour sera mise
> à jour quand ce sera prêt…

Comme indiqué précédement, je ne remet pas en cause les actions à réaliser, seulement la manière de les réaliser. L'utilisateur final, pour moi ce 
n'est pas un informaticien. Il ne doit pas se soucier de son système. Ce qu'il veut c'est l'utiliser et qu'il marche de manière sécurisé. Je ne dis 
pas que c'est facile bien au contraire. Il est très difficle de réaliser quelque chose de simple en apparence.

>   Regarde p.ex.
> http://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.fr.h
>tml pour voir la complétude de la procédure.

Oui, cette procédure est nécessaire et directement réalisable par les personnes ayant une certaine connaissance de l'informatique et de Debian. 
Maintenant cette procédure est-elle réalisable par le biais d'un GUI compréhensible par le commun des mortels.

>
> > Ma question:
> > Comment peut-on simuler/tester la procédure qui sera réaliser
> > lors de la sortie de Squeeze ? Mon objectif étant d'apprécier
> > son côté user-friendly.
>
>   Ben cf. la même référence : c’est long, c’est complet, c’est
> technique, donc c’est pas neuneu-amical, c’est admin-amical…

Sans cracher dans la soupe (je suis un admin-amical ;-)), Debian n'a-t-il pas vocation à être un OS Universel ? Dans cette notion, je comprend qu'en 
plus d'être universel dans son type d'utilisation, ses architectures, et bientôt ses noyaux (ça c'est vraiement génial, j'aurais telement voulu voir 
un Debian/kOpenSolrais ... mince CDDL ... je m'écarte du sujet ...), il est également universel dans son utilisation et plus particulièrement dans 
son accessibilité. Elle ne doit pas être restriente aux connaisseurs, mais également aux utilisateurs (au premier sens du terme).

Enfin, pour faire avancer techniquement la problématique du reboot (c'est bien beau de parler, mais il faut proposer !), ne peut-on associer (Tag ou 
autre) une notion de séquence d'installation à un paquet "DANS LE CAS D'UN UPGRADE". Par exemple, dans notre cas trois séquences nommées "séquence 
#1", "séquence #2" et "others".

On associe le kernel à séquence #1, les outils apt à séquence #2, tous les autres paquets à others.
Pour terminer, on défini également des caractèristiques supplémentaires à une séquence notament un flag stipulant la nécessité de reboot en fin de 
séquence. Dans notre cas, la séquence #1 serait flager "reboot after upgrade successful = YES" par exemple.


... je sais c'est pas facile.
Bon week-end.
Salokine



Reply to: