[Linux-bruxelles] Debian or not debian

[Hervé Eychenne]

On Wed, Jun 09, 2004 at 01:57:22PM +0200, Frederic Peters wrote:

> Hervé Eychenne écrivait :

> > De plus, tu parles du nombre de packageurs. Mais mon sentiment est
> > qu'il n'y en a pas assez, de packageurs. Ce que je veux dire, c'est
> > qu'il y a des packageurs Debian qui ont la charge de 15 ou 20 packages
> > à eux seuls. Et pas des moindres. Ce n'est pas normal. D'autres

> Pourquoi (n'est-ce pas normal) ?

Parce qu'un être humain n'a raisonnablement pas la faculté de gérer
tant de choses à la fois, et surtout de les gérer en temps et en
heure.
Il serait intéressant de noter combien de paquets debian ne sont pas à
jour par rapport à la version upstream (avec une latence moyenne de 4j,
disons).
(hélas, faire de telles statistiques n'est pas possible, car il n'est
pas possible de connaître de manière automatique le dernier numéro de
version upstream en date d'un logiciel donné... encore quelque chose
qui devrait être disponible, unifié, et standard... et qui ne l'est
pas).

> > packageurs sont si peu réactifs qu'on se demande parfois pourquoi ils
> > ne "orphanent" pas leurs packages. Et Debian est incapable de régler
> > cette situation (le NMU = Non Maintainer Upload n'est pas une
> > solution très satisfaisante).

> Pourquoi (n'est-ce pas une solution très satisfaisante) ?

Parce qu'un NMU est toujours un constat d'échec pour le mainteneur
principal, car il n'a pas été assez diligent ou réactif.
Et parce que personne ne connaît en général mieux le packaging d'une
application que son mainteneur. Le NMU, c'est pour moi un peu comme
l'avortement. C'est bien que ça existe, mais l'idéal est de faire en
sorte que l'on y ait pas recours. :-)

> > Ce qui prédomine, c'est "si personne ne
> > le fait, c'est que personne n'a envie de le faire, et c'est tout". Bref,

> Pourquoi (serait-ce un problème) ?

C'est un problème récurrent dans le monde du bénévolat. Ma position
est que quand on décide de faire quelque chose, il faut le faire bien.
Et quand on réalise qu'on est plus capable de le faire bien (même
temporairement), il faut passer la main (même si ce n'est que temporaire).

> > il est facile de prendre en charge un nouveau paquet, mais rien n'est
> > prévu en cas d'inefficacité notoire (j'ai quelques anciens exemples en
> > tête) du mainteneur.

> Pourquoi (dis-tu cela alors que ce n'est pas le cas (que rien n'est
> prévu)) ?

Y a-t-il quelque part dans les statuts de Debian quelque chose qui se
rapporte à la révocation d'un développeur ? (ou en tout cas à la
révocation de son statut de mainteneur pour un paquet donné)

Prenons le cas d'un mainteneur en charge d'un paquet affecté d'un bug
"release-critical" pour lequel il existe un patch connu.
Par exemple, est-il marqué quelque part qu'un tel développeur
incapable d'uploader un nouveau paquet pendant plusieurs mois
sans explication valable doit être révoqué ? Pas que je sache, sinon
je n'en aurais pas vu autant.
Un défaut majeur de Debian, selon moi, est son incapacité à faire
respecter des délais. Du coup, le projet ne cesse de dérapper en
longueur.

> > Mais je pense que le fond du problème n'est pas là. Le fond du
> > problème est que pour une application donnée, il y a environ 5 ou 6
> > personnes qui font grosso-modo le même travail de packaging (mais avec
> > des outils et formats différents). Mon Dieu, que d'énergie
> > gaspillée... que de temps perdu.

> Et KDE et GNOME.  Que d'énergie gaspillée.
> Et ces 45 (QUARANTE-CINQ) gestionnaires de fenêtres.  Que d'énergie
> gaspillée.
> Et cette dizaine de clients IRC.  Que d'énergie gaspillée.
> Et Linux et FreeBSD et NetBSD et OpenBSD et Darwin et Hurd et
> d'autres.  Que d'énergie gaspillée.
> Etc.

Dans un certain sens, oui. Mais non. Pas dans tous les cas.
Tout le monde s'accorde à dire que les deux types de packages (rpm et
deb) ne sont pas très éloignés l'un de l'autre :
http://www.kitenet.net/~joey/pkg-comp/
A mon avis, l'existance de ces deux formats ne se justifie que d'un
point de vue historique, absolument pas technique.

KDE et Gnome sont très différents (même s'ils ont une partie de buts
communs). Une bonne moitié de gestionnaires de ces quarante-cinq
gestionnaires de fenêtres, ou de tous ces clients irc ne servent à
rien d'autre que de joujou pour leurs auteurs et leurs quelques fans.
C'est leur droit. :-) Mais peu importe, car ce qui compte, ce n'est
pas vraiment l'implémentation, mais l'émergence de choses réutilisables
et de bons standards (de fait, ou pas).
Or il manque tellement de choses... tellement.

> > L'essentiel des informations de packaging devraient être contenues
> > dans l'application upstream elle-même (sûrement dans
> > autoconf/automake).

> Et quand on veut faire plus que l'essentiel ?

Précise... je ne comprends pas.

> Ou quand le développeur
> upstream n'est pas d'accord avec les conventions utilisées ?

Il a toujours le choix d'utiliser autre chose.

> Ou quand
> le développeur upstream ne veut pas voir un problème de licence là où
> il y en a pourtant un ?  Etc.

Ceci est un cas tout à fait différent. De toute façon, c'est toujours
le développeur qui décide de ce qu'il est prêt à faire, ou pas.

> > Et par pitié, il ne devrait y avoir qu'un seul format de package, avec
> > une unification aussi poussée que possible au niveau du LSB, et la
> > mise à disposition de toutes les caractéristiques différentes entre
> > distributions dans un fichier commun et parsable.

> Et ce format devrait pouvoir être manipulé avec des outils standards.
> Hint: ar.  Hint: tar.  Hint: gz.  Hint: pas de rpm2cpio.

Ce n'est pas absolument indispensable. Pour quelle raison cela
devrait-il être absolument nécessaire ? Je ne vois pas.

> > Je suis fatigué de voir tout le monde refaire la même chose plus ou
> > moins bien dans son coin, pour n'aboutir qu'à n versions plus ou moins
> > similaires, mais toutes plus ou moins imparfaites au final.

> Moi ça va.

Manque d'"exigence" ? ;-)

 Hervé

-- 
 _
(°=  Hervé Eychenne
//)  Homepage:          http://www.eychenne.org/
v_/_ WallFire project:  http://www.wallfire.org/