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

[**LONG**] Re: [re-encore] de la signification du mot "stable" dans Debian



désolé pour le délai... problème de mail

On Fri, 20 Sep 2002 14:06:19 +0200
Yannick Roehlly <yannick.roehlly@free.fr> 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:georges.mariano@inrets.fr     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



Reply to: