[Linux-bruxelles] Debian or not debian

[Frederic Peters]

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) ?


> 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) ?

>                                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) ?


> 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)) ?


> 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.


> 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 ?  Ou quand le développeur
upstream n'est pas d'accord avec les conventions utilisées ?  Ou quand
le développeur upstream ne veut pas voir un problème de licence là où
il y en a pourtant un ?  Etc.


> 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.

Je pense que certains ne sont pas d'accord.


> 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.



        Frédéric

-- 
Clear Channel ou comment aider la réélection de Bush Jr en allant
à Rock Werchter !  -> toutes les infos sur http://www.hailtocc.org