d�sol� pour le d�lai... probl�me de mail On Fri, 20 Sep 2002 14:06:19 +0200 Yannick Roehlly <[EMAIL PROTECTED]> wrote:
> Justement, la notion de mise � jour chez Debian n'est-elle > effectivement celle que tu d�cris dans ton message, � sa voir le > passage "complet" d'une distribution � l'autre. je reviendrai en fin de message sur cette notion de passage "complet" > J'avais cru comprendre que si tu voulais utiliser dans une > distrib n un paquet pr�sent dans une distribution n+1 il fallait > utiliser des paquets "r�tro-port�s" (ou effectuer le > r�tro-portage soi-m�me le cas �ch�ant). Bon, faisons le "tutorial-tour" de la question : Soient D1 et D2 deux distribution successives, S1 (resp S2) un soft/paquet de D1 (resp D2) qui d�pend d'une librairie L1 (resp L2). Supposons que D1=stable et D2=testing L'utilisateur en stable (D1) souhaite n�anmoins utiliser le soft S2, il pointe donc sur D2 et par apt-get install va r�cup�rer automatiquement S2 *et* L2. OK. Il peut arriver toutefois que : a) S2 se contente en fait de S1 b) l'utilisateur ne souhaite pas upgrader L1 en L2 => on fait alors un backport(recompilation) de S2 dans un contexte D1, en cas de r�ussite la d�pendance est maintenant sur L1 (et pas L2). S2 s'installe alors proprement dans D1. [exemple : L1=xlibg6g/X3.6/potato L2=xlibs/X4.0/woody, S1/S2 un soft X11 quelconque.] Le backport est donc utilis� pour restreindre au strict minimum les d�pendances "trop fortes" et donc le nombre de paquets � upgrader. Plus globalement, � un instant t trois distributions existent stable/testing/unstable. Elles peuvent �tre r�sum�es en fait � 3 graphes de d�pendances G1(woody), G2(sarge) et G3(sid). D'un point de vue "release", les trois graphes sont distincts et s�par�s. Mais, en placant les trois lignes ad�quates dans un sources.list, l'utilisateur "fusionne" ces trois graphes en un seul. En fait, il y � (�ventuellement) 4 graphes si on y ajoute G0, le graphe potentiellement d�j� en place... potato ! Lorsque vous installez la derni�re stable, ce qui vous est "assur�" c'est la coh�rence du graphe G1, parce qu'une _installation_ c'est la mise en place de G1... et pas n�cessairement la transition de G0 vers G1! �videmment, G1 �tant �labor� � partir de G0, la transition devrait n�anmoins se passer de mani�re raisonnable. H�las, la dur�e de construction de la nouvelle stable (+18mois) induit qu'en fait les mainteneurs travaillent essentiellement dans un contexte G1(en travaux) et donc les paquets n'int�grent pas/plus les exigences du passage de G0 � G1. Pour �viter ce type de probl�me, un mainteneur devrait construire ses paquets dans un contexte G0 augment� du strict n�cessaire de G1 (en gros, un backport). Des tachniques et outils existent pour cela (chroot/pbuilder/...). Mais �videmment c'est plus lourd :-( Bref, en th�orie, la puissance du syst�me de paquet Debian devrait donc permettre � un utilisateur de ne piocher que les paquets strictement n�cessaires � ses besoins (e.g dans mon cas, je suis en G0 et je pointe sur G1). C'est une mise � jour incr�mentale (et proche du minimum). Cette politique � l'avantage, ou inconv�nient, de d�celer les probl�mes (quasi in�vitables) de _transition_ G0->G1. Pour les �viter, il "suffit" d'�liminer l'effet transition en basculant tout dans G1. Si l'esprit GNU/Linux est plut�t dans l'esprit "mise � jour incr�mentale", on arrive n�anmoins � la suggestion paradoxale qu'il vaut mieux mettre � jour "� la windows"! La confusion incr�mentale/totale de Debian provient du fait que la Debian est disponible en permanence en mode incr�mental (testing/sid) mais non garanti et **ponctuellement (tous les 2 ans;-)** en mode total (stable) garanti... Alors oui, la notion de mise � jour Debian est sans doute (implicitement) totale. Mais il reste un gros hic. Dans le cas de machines d�j� op�rationnelle, une mise � jour totale c'est 200/300 paquets modifi�s, sans doute quelques confs �cras�es et des pertes de services ... J'arr�te l�. Ce long message est quand m�me une version simplifi�e des choses... Mais �a valait sans doute la peine car avoir une (bonne?) intuition de ces probl�mes c'est probablement des soucis en moins ... PS : � caser dans la debfr FAQ ?? -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue �lis�e Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
