[Linux-bruxelles] Debian or not debian

Mer 25 Aou 14:09:11 CEST 2004

On Thu, 2004-06-10 at 00:58, Hervé Eychenne wrote:
> On Wed, Jun 09, 2004 at 11:00:38PM +0200, Frederic Peters wrote:
> 
> > Hervé Eychenne écrivait :
> 
> > > > Tant de chose ?  Une vingtaine de paquets ?  Ça va.
> 
> > > Mon Dieu, c'est encore bien pire que je ne croyais :
> > > $ apt-cache dumpavail | sed -n 's/^Maintainer:.*</</p' | sort | uniq -c
> > >   | sort -n | less
> 
> > > Edifiant.
> 
> > De ces infos, comment arrives-tu à connaître le temps nécessaire pour
> > un paquet / le temps disponible par le développeur pour Debian ?
> 
> Je n'ai pas besoin de faire de comptes d'apothicaire pour voir
> qu'environ 194 mainteneurs (sur 1299) s'occupent de plus de 20
> packages chacun. Et que 8527 packages sur 14146 sont donc maintenus par
> quelqu'un qui a au moins 20 packages en charge.
C'est toujours comme ça. Sauf que tu nous montres que Debian fait bien
mieux que ce que je peux constater dans d'autres domaines avec des
bénévoles: je vois rarement plus de 10% des gens s'occuper efficacement
de quelque chose, or ici tu nous montres qu'environ 1/6 des développeurs
Debian est actif. Je trouve cela bien.

> Je sais que tu vas essayer de m'entraîner sur le terrain de la
> constestation des chiffres et des méthodes de calcul, mais je n'ai pas
> l'intention de rentrer dedans. Il est pour moi évident que l'on ne
> peut pas gérer plus de 20 packages correctement.
> 
> Il est d'ailleurs intéressant de mettre en parallèle le nombre de
> packages maintenus par une personne donnée et le nombre de bugs
> release-critical associé à ce mainteneur.
À mon avis, les bugs RC si longtemps avant une release n'ont pas de
signification importante.

> nbr_RC : nombre de bugs release-critical (empêchant le passage de
>   sarge en stable) détenu par ce mainteneur
Il n'y a pas que cela, il y a aussi d-i.
> nbr_maintenus : nombre de paquets gérés par ce mainteneur
> 
>  adresse          nbr_RC  nbr_maintenus
> 
> coven at debian.org    14    40
> kitame at debian.org   10   108
> gibreel at debian.org   9   108
> rkrusty at debian.org   7    32
> mhatta at debian.org    6    77
> dres at debian.org      6    25
> turbo at debian.org     5    96
> gopal at debian.org     5    21
> foka at debian.org      5    64
> tv at debian.org        4    38
> 
> Là encore, très édifiant.
> J'attends avec impatience de voir à quel détail tu vas t'accrocher
> pour démontrer que j'ai tort d'affirmer que bon nombre de
> développeurs gèrent bien trop de paquets à la fois.
Il faut surtout savoir que dans ta liste, plusieurs autorisent
explicitement les NMU sur leurs packages, et n'en sont pas moins bons
pour traiter les problèmes qu'ils peuvent.

> > > > De plus en plus de paquets incluent des fichiers .watch qui permettent
> > > > justement ça.
> 
> > > De quoi s'agit-il exactement (techniquement) ?
> > > $ cd /var/cache/apt/archives ; for i in *.deb ; do dpkg -c $i ; done | fgrep .watch
> > > ne donne rien, et un moteur de recherche Web non plus.
> 
> > Le mien me donne des infos pertinentes.  debian watch files
> 
> Ok, c'est bien que ce mécanisme existe. Mais :
> - tout bon mainteneur d'un paquet devrait être abonné à la
>   mailing-list de l'application qu'il package. Il ne devrait donc en théorie
>   pas avoir besoin de fichiers watch.
Les fichiers watch ne servent pas qu'au mainteneur du package. Ils
servent aussi pour tous les autres, et aussi pour faire des stats et
tenter d'améliorer la transparence et la qualité de Debian. Faire cela
manuellement n'aurait aucun sens.
De plus, il existe plein de projets qui n'ont pas de ml, ni d'annonces
ni de quoique ce soit.
> - il devrait y avoir un repository libre recensant les projets libres
>   et leurs différentes versions. Ne me parlez pas de freshmeat, ce
>   n'est pas libre. Conséquence : leur peur de voir leur base de
>   données pillée et l'absence d'accès au code source de leur backend
>   fait qu'il est en pratique impossible de programmer des outils
>   fiables permettant de faire ce qu'il faudrait faire, à savoir une
>   library de fonctions d'accès à la base et l'outil en ligne de
>   commande (et X, pourquoi pas) permettant de :
>   - mettre à jour automatiquement la base pour le développeur (avec
>     signature)
>   - faire des requêtes dans la base
Ça pourrait être une bonne idée. Mais alors, pourquoi ne pas utiliser
les fichiers watch de Debian comme base pour composer cela?

> Mais la question n'est même pas là. La question initiale était en
> substance : un mainteneur ne devrait pas avoir besoin d'un outil
> automatique pour être informé de la sortie d'une nouvelle version, car
> il est censé suivre le logiciel un peu au jour le jour, sinon c'est
> bien moins sérieux. On considère donc que cela devrait être le cas dès
> aujourd'hui. Comment, donc, expliquer de tels retard de packaging pour
> bon nombre applications ? (je ne parle pas des applications difficiles
> à packager, comme kde, X, ou autres)
Tu es informaticien (et développeur), et tu trouves que le mainteneur ne
devrait pas avoir trop d'outils automatiques pour l'aider???

[..]

> Je n'ai pas le coeur de chercher des exemples actuels, mais ce qui me
> vient à l'esprit en vrac à cette heure sans recherche aucune :
> - kde : chaque release de KDE est suivie quasiment immdiatement de la
>   mise à disposition de paquets Debian sur le site de KDE, et il faut
>   plusieurs mois aux mainteneurs Debian s'occupant de KDE pour arriver
>   à sortir un paquet "Debian officiel".
Parce que les développeurs Upstream de KDE ne sont pas assez
perfectionnistes: ils ne testent pas forcément avec la version de GCC
dans Debian, ni certainement sur la moitié des plateformes supportées
par Debian. De plus, ils ne se soucient pas de l'intégration avec
d'autres applications ou environnements (comme GNOME par exemple).
> - discover : il est resté pendant des mois sans la moindre activité,
>   alors qu'il aurait dû constituer à mon sens l'essentiel des efforts de
>   Debian ! (sachant son retard sans l'auto-configuration par rapport à
>   tant d'autres distributions)
Discover2 était en grands travaux, et donc plus beaucoup de développeurs
ne travaillaient sur la version 1.
> - http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&data=fixed-upstream&archive=no
>   et regarder l'ancienneté des bugs corrigés en upstream, mais pas
>   dans le paquet Debian correspondant. Il y a en tout de même
>   beaucoup, et ils sont souvent très vieux.
> 
> > > > Non.  Peut-être parce que l'opinion qu'exclure quelqu'un est un acte
> > > > grave est partagée par la plupart des développeurs Debian ?
> 
> > > <troll>"Tout le monde sait qu'untel est notoirement inefficace, mais il est
> > > indéboulonable". On se croirait dans la fonction publique...</troll>
> 
> > Je ne vois pas qui est notoirement inefficace.
> 
> Redite :
> - certains développeurs qui ont bien trop de paquets à gérer et/ou qui
>   les gèrent mal
On n'est pas forcément d'accord.
> - incapacité de Debian à produire une distribution stable à intervalle
>   raisonnable
Il y a plusieurs projets intéressants pour contourner ce problème, en
voici une: "Componentized Linux" de Progeny.

[..]

> > > > Mais l'utilisateur de Debian qui se retrouve avec une applic non
> > > > intégrée dans les menus parce que "monsieur le développeur trouve que
> > > > les menus, c'est nul"; qu'en fait-on ?
> 
> > > Qu'en fait-on de qui ? Du développeur ? Eh bien son programme est
> > > moins bien intégré dans Debian, ou alors Debian peut toujours rajouter
> > > un mécanisme supplémentaire pour qu'il soit intégré correctement.
> > > Il y aurait des développeurs grincheux, mais je pense que ça serait
> > > marginal, et tant pis pour eux.
> 
> > Voilà, "Debian peut toujours rajouter".  C'est ce que Debian fait.
> 
> Oui. Et je dis que Debian le fait trop souvent, car l'appli ne donne pas
> spontanément l'infrastructure nécessaire, alors qu'elle le devrait.
D'accord, mais changer les habitudes de tous les développeurs de
logiciels libres est à mon avis encore un cran au-dessus d'améliorer
Debian, point de vue réalisation.

[..]

> > > Bref, ton argument n'est pas valable (car a contrario tu pourrais tout aussi
> > > bien dire qu'à ce compte-là tu n'aurais nulle envie d'installer ar
> > > pour pouvoir accéder au contenu d'un .deb).
> 
> > ar est standard, je l'ai vu installé sur des systèmes qui étaient loin
> > d'être des Unix libres...
> 
> Redite/résumé :
> Si tu veux voir à la main le contenu d'un package (ce qu'une partie
> infîme des utilisateurs du paquet est censée faire), tu installes le
> logiciel qui te le permet, et ce logiciel devrait être l'outil natif de
> gestion des packages (dpkg ou rpm).
J'ai déjà eu l'utilité d'un fichier de configuration contenu dans un
.deb sur une Sparc avec Solaris. Ça te va comme exemple?


-- 
Jerome Warnier <jwarnier at beeznest.net>
BeezNest s.a r.l.