[Linux-bruxelles] Debian or not debian

Jeu 10 Juin 00:58:15 CEST 2004

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.

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.

nbr_RC : nombre de bugs release-critical (empêchant le passage de
  sarge en stable) détenu par ce mainteneur
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.

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

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)

> > > Pourquoi directement penser à révoquer ?  C'est une solution extrème,
> > > à mes yeux.

> > Laisser un paquet à l'abandon pendant des mois n'est pas un
> > exemple d'inefficacité extrême, peut-être ?

> Tu dois modérer ton langage (abandon, extrème) et fournir des exemples :)

J'assume les termes. Un paquet qui n'a pas évolué depuis plusieurs
mois alors que la version upstream est active est proprement
"abandonné". Quant au terme "extrême", je ne fais que reprendre le tien
(rhétorique, ok).

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".
- 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)
- 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
- incapacité de Debian à produire une distribution stable à intervalle
  raisonnable

> > Cela dit, je ne vois pas le rapport avec le point de départ de ta
> > remarque, à savoir
> > «L'essentiel des informations de packaging
> > devraient être contenues dans l'application upstream elle-même (sûrement
> > dans autoconf/automake).»

> Ma compréhension du dialogue:
>  HH] -- l'essentiel des informations de packaging...

<mode=fpeters>Qui est HH ?</mode> ;-)
Ah, ok. HE].

>  FP] -- il n'y a pas que l'essentiel
>  HH] -- ?
>  FP] -- par exemple logrotate, ce n'est pas essentiel, mais bien
>  HH] -- si, c'est essentiel, je ne vois pas le rapport
>  FP] -- ok, la rotation de log est essentielle, mais X ne l'est pas,
>      et pourtant, je veux que mon paquet aie X
>  HH] -- ...

Que ton paquet ait X ? Je suppose que tu ne parles pas de X11...
(ambigu)
Eh bien rien ne t'empêche d'ajouter X à ton paquet. Et ?

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

> Idéalement, il n'y aurait rien à faire.  Mais il faut intégrer
> correctement et ça nécessite souvent des modifications.

Oui. Des modifications ponctuelles seront toujours nécessaires. Mais
il y a une marge de progression énorme par rapport à l'existant,
je trouve.

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

 Hervé

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