On Tue, Jun 24, 2003 at 09:32:52AM +0200, Georges Mariano wrote: [...] > >prenons l'exemple > > de perl. Le paquet eperl dépend de libperl5.6 dans stable et > > libperl5.8 dans unstable. > > J'attends donc que tu nous expliques comment mettre à jour perl et > > eperl si les paquets sont compilés en stable. > > je connais pas ces applis, ... quelle est la motivation de l'upgrade ? [...]
Puisque les cas concrets ne t'intéressent pas, soient A et B deux paquets, qui seront supposés pour simplifier avoir les mêmes noms en paquets source et binaire. On note vA1 et vA2 les versions des programmes (choisies par upstream) de A, et dA1 et dA2 les numéros de révision Debian. On introduit des notations similaires pour le paquet B. Supposons que A a besoin pour s'exécuter de la version de B qui a servi lors de la compilation, et plus précisément de vB, quel que soit dB. Les paquets se trouvent dans stable dans les versions vA1dA1 et vA2dA2. Maintenant, les utilisateurs demandent à ce que les nouvelles versions soient mises dans la version stable, il suffit de regarder www.apt-get.org pour s'en rendre compte. Il faut donc réussir à faire rentrer A vA2 et B vB2 dans stable. Pour cela, on me propose de faire rentrer d'abord B vB2. Mais alors A vA1 ne peut plus marcher avec B vB2, et cette distribution soi-disant plus stable est obligatoirement cassée. On me répondra que le paquet A vA2 va suivre rapidement, mais rien n'indique qu'il soit facile de compiler A vA2 avec B vB2, on risque donc d'avoir un cassage pendant une durée non négligeable. Pourquoi ce problème n'existe-t-il pas si on compile en unstable ? Il existe, et unstable est cassé de la même façon, mais ces paquets cassés ne vont pas rentrer dans testing. On commence par faire rentrer B vB2, puis on compile A vA2 avec B vB2, et lorsque tout est bon, les programmes peuvent migrer vers testing. La distribution unstable joue son rôle de tampon. Avec la « solution » proposée, ce rôle de tampon sera joué par la distribution stable. Brillante idée ! Denis