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
Attachment:
pgp2u2Uaq1BMd.pgp
Description: PGP signature