Mauvaise distribution, changer de distribution, voir Gentoo.
Par contre, il existe un outil nommé apt-build, mais est-ce bien utile ?
En outre, tu peux toujours t'amuser à monter un serveur buildd, si ça
t'amuse ;-)
Je ne comprends pas ta question.
http://www.kitenet.net/~joey/debconf-debconf/tutorial-doc.html
Si tous les utilisateurs de l'unstable comprenaient le rôle important
qui leur incombent en utilisant cette distribution, ils joueraient mieux
leur rôle de garde-fou. Maintenant, s'il s'agit de paquets de cette
distribution dont tu parles, alors, cet argument tombe en pièces.
A toi de faire attention à ce que tu fais avec apt. Après tout, tu n' es
pas obligé d'installer exim avec gforge si tu précises que tu veux
gforge-mta-postfix (et tu noteras que tu as toujours sympa,, juste
mailman en plus, de même pour le couple apache/apache2. Putain, tu
utilises les mêmes logiciels que moi !). Mais j'avoue que gforge est à
réserver à un hôte dédié. Par contre, c'est un cas particulier, pour ne
pas dire unique. Trouve donc un autre exemple.
Ce n'est pas un travail toujours facile et plutôt ingrat mais si tu veu x
aider Roland Mas et Christian Bayle, ils seront ravis.
Il existe une méthode similaire, bien que moins "packagée", inspiré de
JumpStart (pour ceux qui connaissent Solaris) et nommée KickStart.
Evidemment, pour utiliser un serveur TFTP et tout le tromblon, faut le
faire soi-même, mais c'est possible.
Mauvaise distribution, changer de distribution, voir Gentoo.
Par contre, il existe un outil nommé apt-build, mais est-ce bien utile ?
En outre, tu peux toujours t'amuser à monter un serveur buildd, si ça
t'amuse ;-)
Je ne comprends pas ta question.
http://www.kitenet.net/~joey/debconf-debconf/tutorial-doc.html
Si tous les utilisateurs de l'unstable comprenaient le rôle important
qui leur incombent en utilisant cette distribution, ils joueraient mieux
leur rôle de garde-fou. Maintenant, s'il s'agit de paquets de cette
distribution dont tu parles, alors, cet argument tombe en pièces.
A toi de faire attention à ce que tu fais avec apt. Après tout, tu n' es
pas obligé d'installer exim avec gforge si tu précises que tu veux
gforge-mta-postfix (et tu noteras que tu as toujours sympa,, juste
mailman en plus, de même pour le couple apache/apache2. Putain, tu
utilises les mêmes logiciels que moi !). Mais j'avoue que gforge est à
réserver à un hôte dédié. Par contre, c'est un cas particulier, pour ne
pas dire unique. Trouve donc un autre exemple.
Ce n'est pas un travail toujours facile et plutôt ingrat mais si tu veu x
aider Roland Mas et Christian Bayle, ils seront ravis.
Il existe une méthode similaire, bien que moins "packagée", inspiré de
JumpStart (pour ceux qui connaissent Solaris) et nommée KickStart.
Evidemment, pour utiliser un serveur TFTP et tout le tromblon, faut le
faire soi-même, mais c'est possible.
Mauvaise distribution, changer de distribution, voir Gentoo.
Par contre, il existe un outil nommé apt-build, mais est-ce bien utile ?
En outre, tu peux toujours t'amuser à monter un serveur buildd, si ça
t'amuse ;-)
Je ne comprends pas ta question.
http://www.kitenet.net/~joey/debconf-debconf/tutorial-doc.html
Si tous les utilisateurs de l'unstable comprenaient le rôle important
qui leur incombent en utilisant cette distribution, ils joueraient mieux
leur rôle de garde-fou. Maintenant, s'il s'agit de paquets de cette
distribution dont tu parles, alors, cet argument tombe en pièces.
A toi de faire attention à ce que tu fais avec apt. Après tout, tu n' es
pas obligé d'installer exim avec gforge si tu précises que tu veux
gforge-mta-postfix (et tu noteras que tu as toujours sympa,, juste
mailman en plus, de même pour le couple apache/apache2. Putain, tu
utilises les mêmes logiciels que moi !). Mais j'avoue que gforge est à
réserver à un hôte dédié. Par contre, c'est un cas particulier, pour ne
pas dire unique. Trouve donc un autre exemple.
Ce n'est pas un travail toujours facile et plutôt ingrat mais si tu veu x
aider Roland Mas et Christian Bayle, ils seront ravis.
Il existe une méthode similaire, bien que moins "packagée", inspiré de
JumpStart (pour ceux qui connaissent Solaris) et nommée KickStart.
Evidemment, pour utiliser un serveur TFTP et tout le tromblon, faut le
faire soi-même, mais c'est possible.
Fri, 17 Dec 2004 20:43:44 +0100, François Boisson a écrit :
> Le Fri, 17 Dec 2004 19:38:56 +0100
> Sylvain Sauvage a écrit:
>
> > La stabilité d'une debian se mesure *surtout* dans la stabilité du
> > système de paquet : en clair des dépendances. Donc que tu ne
> > puisse pas recompiler facilement un paquet sid en stable me semble
> > logique.
>
>
> Non, on peut faire du développement sur du stable. Je conçois la
> stabilité comme une arborescence de paquets stables (les noeuds) sur
> lesquels on accroche des paquets terminaux qui, eux, peuvent venir
> de l'instable. Je suis sous woody et j'ai compilé sylpheed-1.00beta4
> (disponible chez moi d'ailleurs) pour avoir des fonctionnalités
> importantes: le reply-to-liste n'existe pas dans le sylpheed de la
> woody. [...] Il est quand même curieux qu'on ne puisse pas
> recompiler simplement ces paquets sous woody. Une solution serait
> peut être de classifier les paquets en fonction de leur statut
> (noeud ou feuille) dans l'arborescence des paquets et éventuellement
> de leuyr profondeur. On pourrait alors demander des exigences plus
> importantes dans la recompilation pour des paquets terminaux.
Les responsables de paquets produisent plus d'efforts pour qu'à un
instant donné le graphe soit stable en terme de dépendances, avec des
versions assez stables et assez récentes des feuilles (et des n_uds).
[...]
Fri, 17 Dec 2004 20:43:44 +0100, François Boisson a écrit :
> Le Fri, 17 Dec 2004 19:38:56 +0100
> Sylvain Sauvage <Sylvain.Sauvage@metanoesis.net> a écrit:
>
> > La stabilité d'une debian se mesure *surtout* dans la stabilité du
> > système de paquet : en clair des dépendances. Donc que tu ne
> > puisse pas recompiler facilement un paquet sid en stable me semble
> > logique.
>
>
> Non, on peut faire du développement sur du stable. Je conçois la
> stabilité comme une arborescence de paquets stables (les noeuds) sur
> lesquels on accroche des paquets terminaux qui, eux, peuvent venir
> de l'instable. Je suis sous woody et j'ai compilé sylpheed-1.00beta4
> (disponible chez moi d'ailleurs) pour avoir des fonctionnalités
> importantes: le reply-to-liste n'existe pas dans le sylpheed de la
> woody. [...] Il est quand même curieux qu'on ne puisse pas
> recompiler simplement ces paquets sous woody. Une solution serait
> peut être de classifier les paquets en fonction de leur statut
> (noeud ou feuille) dans l'arborescence des paquets et éventuellement
> de leuyr profondeur. On pourrait alors demander des exigences plus
> importantes dans la recompilation pour des paquets terminaux.
Les responsables de paquets produisent plus d'efforts pour qu'à un
instant donné le graphe soit stable en terme de dépendances, avec des
versions assez stables et assez récentes des feuilles (et des n_uds).
[...]
Fri, 17 Dec 2004 20:43:44 +0100, François Boisson a écrit :
> Le Fri, 17 Dec 2004 19:38:56 +0100
> Sylvain Sauvage a écrit:
>
> > La stabilité d'une debian se mesure *surtout* dans la stabilité du
> > système de paquet : en clair des dépendances. Donc que tu ne
> > puisse pas recompiler facilement un paquet sid en stable me semble
> > logique.
>
>
> Non, on peut faire du développement sur du stable. Je conçois la
> stabilité comme une arborescence de paquets stables (les noeuds) sur
> lesquels on accroche des paquets terminaux qui, eux, peuvent venir
> de l'instable. Je suis sous woody et j'ai compilé sylpheed-1.00beta4
> (disponible chez moi d'ailleurs) pour avoir des fonctionnalités
> importantes: le reply-to-liste n'existe pas dans le sylpheed de la
> woody. [...] Il est quand même curieux qu'on ne puisse pas
> recompiler simplement ces paquets sous woody. Une solution serait
> peut être de classifier les paquets en fonction de leur statut
> (noeud ou feuille) dans l'arborescence des paquets et éventuellement
> de leuyr profondeur. On pourrait alors demander des exigences plus
> importantes dans la recompilation pour des paquets terminaux.
Les responsables de paquets produisent plus d'efforts pour qu'à un
instant donné le graphe soit stable en terme de dépendances, avec des
versions assez stables et assez récentes des feuilles (et des n_uds).
[...]
[...]
(l'intérêt des paquets sources est
considérablement amoindri du coup).
Pour ce genre de paquet, imposer des
paquets sources pouvant se compiler sur une debian stable me paraitrait
vraiment une bonne idée.
[...]
(l'intérêt des paquets sources est
considérablement amoindri du coup).
Pour ce genre de paquet, imposer des
paquets sources pouvant se compiler sur une debian stable me paraitrait
vraiment une bonne idée.
[...]
(l'intérêt des paquets sources est
considérablement amoindri du coup).
Pour ce genre de paquet, imposer des
paquets sources pouvant se compiler sur une debian stable me paraitrait
vraiment une bonne idée.
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 doive nt
ê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 ?)
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 ».
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 à ex pliquer
au /vulgum pecum/, ç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 »).
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 doive nt
ê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 ?)
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 ».
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 à ex pliquer
au /vulgum pecum/, ç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 »).
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 doive nt
ê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 ?)
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 ».
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 à ex pliquer
au /vulgum pecum/, ç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 »).
Le Mon, 10 Jan 2005 22:29:58 +0100
Sylvain Sauvage 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).
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'ét ait
déjà le cas) mais trickle est aussi conçu pour tourner sur ces serv eurs
(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 ce tte
> 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 pet it
> 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 con trole,
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 cla ir 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).
Le Mon, 10 Jan 2005 22:29:58 +0100
Sylvain Sauvage <Sylvain.Sauvage@metanoesis.net> 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).
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'ét ait
déjà le cas) mais trickle est aussi conçu pour tourner sur ces serv eurs
(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 ce tte
> 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 pet it
> 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 con trole,
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 cla ir 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).
Le Mon, 10 Jan 2005 22:29:58 +0100
Sylvain Sauvage 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).
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'ét ait
déjà le cas) mais trickle est aussi conçu pour tourner sur ces serv eurs
(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 ce tte
> 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 pet it
> 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 con trole,
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 cla ir 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).
