Mon, 10 Jan 2005 23:19:43 +0100, François Boisson a écrit : > Le Mon, 10 Jan 2005 22:29:58 +0100 > Sylvain Sauvage <[EMAIL PROTECTED]> a écrit: >[...] > > Je veux bien que quelques paquets ne posent pas de problème, mais quid > > des autres ? (À ce propos, as-tu une indication de ce qui n'allait pas > > avec le paquet source debian ?) > > Utilisation de cdbs et d'outils spécifiques à sid pour batir le paquet > (pour qstat), le problème est là surtout, l'incompatibilité vient > surtout d'eux. A la limite, il suffirait de faire un backport propre de > ces outils ou une adaptation de ces outils à woody avec une > compatibilité ascendante (sid pouvant compiler les woody).
(o: T'as pas essayé de les backporter ? Si ça se trouve, ça fonctionne facilement. Suffirait donc de mettre ces paquets dans les dépendances du paquet source... :o) > Rq: Pour xqf, je viens de vérifier, le paquet unstable se compile donc > c'est moi qui est du faire une fausse manoeuvre pour celui là. > > Le backport est un problème purement lié aux distributions. Je viens de > compiler trickle sur un serveur potato et il marche parfaitement. Je > n'ai pas fait un backport, j'ai compilé un programme pour un linux. Ce > faisant, j'ai évidemment cassé l'estampille Debian du serveur (c'était > déjà le cas) mais trickle est aussi conçu pour tourner sur ces serveurs > (noyau 2.2). C'est (ou plutôt cela aurait été) un backport du paquet > debian trickle, ça n'est pas un backport de trickle. Je comprends bien. Je crois d'ailleurs me souvenir que c'était une partie de nos propos antérieurs (au moins des miens) : les paquets sources sont faits pour une distribution particulière, en l'occurrence sid. > > Imaginons que ce soit réaliste et, même, que ça se fasse. Dans cette > > situation (hypothétique), la question sera alors : pourquoi a-t-on des > > paquets source et pas aussi des binaires ? > > > > On aura une « stable » qui se mettra à jour petit morceau par petit > > morceau sur les paquets « feuilles ». > > L'origine du fil était (je crois, c'est loin) l'explication du succès de > sites de backports officieux (et les reproches faits à Debian). Ces > sites sont une réponse à cela avec l'inconvénient d'être sans controle, > aléatoires et donnent l'impression d'une grande pagaille dans les > paquets debian... Yep, c'est vrai. Il est aussi à noter que certains DD maintiennent eux-mêmes ces backports (je me souviens au moins du cas de XFree86 il y a quelque temps). > > Et là, on nous dira « debian ça pue, ça utilise pas la glibc3 ».. Ok, > > je sens que je vais trop loin là ;oP > > > > D'une façon plus réaliste, des programmes comme le gimp ou kde ne > > pourront en profiter parce qu'ils s'accompagnent d'une foultitude de > > bibliothèques. Ils ont donc l'air d'être « feuilles » alors qu'ils > > sont « n_uds » ou très liés à des n_uds. C'est difficile à expliquer > > au /vulgum pecum/, ça. > > gimp et kde sont surtout des paquets de librairies, ce ne sont pas des > feuilles. C'est effectivement facile à comprendre pour kde, pas pour > gimp sauf quand on le compile j'imagine (pas encore fait ça...) En fait, quand je disais kde, je voulais surtout parler de toutes les applications kde (kate, konqueror, kyle, etc.), qui sont fortement liées à la version des kdelibs (et même entre elles). Un éditeur ou un navigateur, ça ressemble quand même bien à une feuille, c'est pas forcément évident d'expliquer que mettre ktruc à jour demande de mettre toutes les libs et applis kde (ou presque). > > Donc (pfiou, plus long que prévu là), la proposition semble certes > > intéressante mais difficile à réaliser. (Sans compter qu'en fait, ça > > fait sauter tout le système de « rilize » debian et on se retrouve > > plus proche d'une « gentoo stable »). > > Alors, peut être donner la possibilité de compiler sous stable les > utilitaires nécessaires à la création de paquets sous woody (en clair un > backport propre de debhelper, cdbs, etc) en assurant par ailleurs une > compatibilité ascendante des ces outils (le rêve...). Cela ne ferait pas > de travail pour les développeurs/packageurs (sauf ceux de ces outils), > donnerait une souplesse nouvelle à la stable en permettant de la > moderniser ponctuellement sur des paquets feuilles (aux risques des > utilisateurs). D'accord. Mais ça limite quand même les utilisateurs possibles à ceux qui savent/peuvent/veulent utiliser les paquets sources. Remarque que, comme je le disais, si les paquets sources fonctionnent sur toutes les versions, les binaires sont faciles à produire automagiquement... Sinon, il y a : http://wiki.debian.net/index.cgi?ReleaseProposals qui recense les propositions pour modifier le processus de « rilize ». C'est pas une tâche facile. Je n'y ai pas vu de proposition s'approchant de la tienne. À proposer, donc. À noter la dernière (pour le moment) remarque, par BillAllombert : « There are lots of misconceptions about why the Debian releases are delayed and lots of proposals attempt to fix non-existent problems. This cause lots of flamewars on non-issues. » (Je dis ça vis à vis du site, pas de ta proposition.) Dernière petite remarque (que je voulais mettre à la fin du dernier message mais que j'ai oubliée) : moi, je ne sais rien (ça se saurait ;o), je cherche juste à être objectif, quitte à être subjectif en exploitant des arguments parfois fallacieux, à me faire l'avocat du diable pour que tous les arguments puissent apparaître. -- Sylvain Sauvage
