On Wed, 25 Jun 2003 00:58:27 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote:
> C'est l� o� je voulais en venir. Dire qu'il suffit de compiler en > stable pour r�soudre beaucoup de probl�mes �tait simpliste, cela > pose d'autres probl�mes, et il faut appr�hender le tout, ce qui > n'�tait manifestement pas le cas. Je le re-r�p�te, je n'ai pas dis qu'il fallait rester scotcher � stable co�te que co�te (�a c'est TON interpr�tation), j'ai dis qu'il faut repartir de d�pendances "basses" (ie. stables) pour reconstruire un paquet. Et faire les tests dans un contexte stable, puisque c'est ce qu'ont les users sur leurs machines. Le hic, c'est que m�me si un dd fait �a, arriv� sur les autobuilders c'est sid qui est en place (non?), donc EVIDEMMENT, il faut adapter globalement le processus. Compiler dans un contexte plut�t unstable pour obtenir une version stable, ben intuitivement j'ai l'impression que �a rallonge la �convergence�... > Reviens sur l'exemple d'ocaml en byte-code, c'est similaire : certains > paquets utilisent la libperl, et d�pendent alors de la version de perl > utilis�e � la compilation, tout comme un programme ocaml en byte-code > d�pendra de la machine virtuelle. Tout comme j'ai jamais dis qu'il fallait pas tenir compte des contextes particuliers (perl c'est perl, ocaml c'est ocaml). Je ne les mets pas dans le m�me sac (pour essayer de coincer GM ;-) car pour ocaml, en terme de besoin utilisateur, on pourrait fournir du natif et �viter tout ce type de probl�me. Mais on le fait pas. Donc on change d'exemple. Et hop. A+ -- debfr-faq: http://savannah.nongnu.org/download/debfr-faq/html/ val-linux: http://phalompe.homeip.net:9673/val-linux perso: http://www3.inrets.fr/estas/mariano
