Re: Inertie de Debian était : packages debian
Le Mon, 10 Jan 2005 22:29:58 +0100
Sylvain Sauvage <Sylvain.Sauvage@metanoesis.net> 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
Reply to: