On Mon, Feb 25, 2002 at 11:03:24AM +0100, Georges Mariano wrote: > le fait de recompiler ne te sors absolument pas du syst�me de > package. Mais cela n'utilise _QUE_ des manips Debian bas�es sur les > outils apt/dpkg/deb* ... C'est parfaitement propre.
Oui, je suis d'accord... > Le seul co�t (quand �a se passe bien) c'est le temps CPU. Le temps CPU, c'est pas cher. Mais mon temps � moi, il est pr�cieux. Et le temps que le CPU prends, moi je l'attends. >> - XFree86 parce que 3.3.x ne reconna,An(Bt pas notre carte >c'est fait ... (pas encore 4.2 mais 4.1 oui) Oui, mais X on le prends de l�, et gnome de l� et tel autre chose de l�, �a complique la gestion du sources.list :-( Et ces sources "scattered" de backporting, faut les trouver, les chercher, �a prend du temps. > les paquets Ximian ferons l'affaire... h�r�sie! ;-) > > �a fait d�j� un gros morceau! Trop gros, � mon avis. > gros = unit� de mesure (?? lignes de commandes n�cessaires? > temps CPU? espace disque ?... tout est relatif). Temps humain. De plus et surtout, quand les bugs de la version que tu as backport� sont corrig�s, il faut se retaper la compilation. C'est �a que j'entendais par "profiter du syst�me de packages": Mises � jour auto, etc. Pas besoin de "v�rifier" "ah tiens, une nouvelle version, re-backportons". > PS : et si on s'organise un peu cela pourrait �tre fait une fois et > mis � dispo... Bof, je vois pas l'int�r�t, on finirait par faire "woody - libc + libc_de_patate". Ou peut-�tre "testing avec un d�lai de trickle plus grand". Quelle application ne pas backporter? Pourquoi ne pas backporter ceci ou cela? -- Lionel
pgp4ow1w5tJy5.pgp
Description: PGP signature
