Le Mon, 10 Jan 2005 22:29:58 +0100 Sylvain Sauvage <[EMAIL PROTECTED]> a �crit:
> Mon, 10 Jan 2005 21:12:21 +0100, Fran�ois Boisson a �crit : > >[...] > > (l'int�r�t des paquets sources est > > consid�rablement amoindri du coup). > > Il sont l� surtout vis � vis des libert�s du LL : les sources doivent > �tre disponibles. ;o) > > > Pour ce genre de paquet, imposer des > > paquets sources pouvant se compiler sur une debian stable me > > paraitrait vraiment une bonne id�e. > > Le principal boulot du responsable de paquet est de fournir un paquet > (source ou compil�, le compil� �tant souvent auto-compil�) pour la > distribution en cours de d�veloppement. Il doit aussi maintenir le > paquet de la version stable mais seulement pour la s�curit�. > C'est d�j� assez difficile. > > Avoir des paquets source (d'une version amont r�cente) qui compile > _aussi_ pour la stable (ce qu'on appelle le /backport/), �a ajoute du > boulot au responsable de paquet. > Est-ce r�aliste ? > > 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). 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. > 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... > > 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...) > > 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). Fran�ois Boisson
