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
