[Linux-bruxelles] Debian or not debian

Ven 27 Aou 11:45:09 CEST 2004

Le mer 25/08/2004 à 17:08, Hervé Eychenne a écrit :
> Ca c'est du dépilage... :-) Bonne rentrée !
> 
> On Wed, Aug 25, 2004 at 02:09:11PM +0200, Jerome Warnier wrote:
> 
> > 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.
> 
> Comme on peut très bien faire des paquets Debian non officiels dans son
> coin, on peut supposer ("exiger" ?) qu'un enregistrement en tant que
> mainteneur Debian officiel implique un engagement, et donc une
> "garantie" d'activité correcte ?
> Je pense donc que le taux de mainteneurs Debian actifs devrait donc
> être proche de 100%, hors coups de bourre transitoires et bien sûr
> non-évolution du logiciel upstream.
> En cas de difficultés même temporaires, tout mainteneur devrait
> demander de l'aide en vue d'une co-maintenance, et si les difficultés se
> prolongent, elles doivent mener à un "orphaning" du paquet.
> 
> De toute manière, tu as (à dessein, je suppose) retourné mon
> raisonnement pour faire une comparaison avec une association du type
> BxLUG (c'est vrai que c'est la problématique à laquelle ont à faire
> face toutes les associations, mais une adhésion peut dans ce cas se
> réduire à de la sympathie ou un simple apport de cotisation).
C'est bien comme cela que je l'entends. Mais ce serait évidemment mieux
si le BxLUG avait toujours plusieurs projets en cours et que chaque
membre participait activement au moins à l'un d'entre eux.
En fait le BxLUG _a_ plusieurs projets en cours, mais disons qu'ils
vivent par vagues et sont rarement suffisamment documentés pour que
d'autres puissent avoir l'envie d'y participer.
> Je rappelle que mon propos initial était qu'un nombre réduit de gens
> s'occupe de bien trop de paquets Debian importants, avec tout ce que
> cela suppose (surcharge de travail, retards, laxisme, erreurs, absence
> de vérification par les pairs, absence de partage des responsabilités,
> etc.).
Je sais, je sais. Mais encore une fois, le nombre n'explique pas tout,
j'ai encore eu la preuve plusieurs fois il n'y a pas longtemps qu'un
seul gars bien décidé peut faire plus qu'un grand groupe.

> > > 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.
> 
> Alors le terme Release Critical est mal choisi... Il faudrait
> introduire un autre terme, plus neutre, genre non-working.
En fait, Release Critical n'est pas une gravité de bug que tu peux
introduire. C'est en fonction de cette gravité et d'autres choses
automatiques que ça "devient" Release Critical.

[..]

> > > - 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?
> 
> Parce que :
> - ce repository du libre dépasse le cadre de Debian
Mais ce serait un bon début, non? Je ne parle pas de se contenter des
fichiers watch de Debian, mais de partir de là.
> - la mise à jour des versions n'est qu'une part des informations de la
>   base de données
Dans le cadre d'un package Debian tu peux retrouver la licence, une
description courte, longue, son auteur, l'URL où tu peux trouver plus
d'infos, ...
> - plutôt que d'essayer de traquer les nouvelles versions
>   automatiquement (ce qu'il n'est pas possible de faire en totalité
>   de manière fiable et universelle), cette mise à jour de la base
>   devrait d'abord se faire au niveau des mainteneurs upstream
>   eux-mêmes, via un fichier simple et une commande publish qui ferait
>   tout ce qu'il y a à faire. Le tout étant complété par des anonymes,
>   avec modération éventuelle.
Donc, tu proposes un truc manuel? Je m'étonne encore que tu sois
informaticien!
> - il existe déjà 2 autres sources d'information intéressantes, à
>   savoir freshmeat et le GNU software directory.
Et c'est trop?

> > > 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 pense qu'un mainteneur Debian doit s'intéresser au développement de
> l'upstream et le suivre de manière rapprochée. Quand tel est le cas,
> passer à côté d'une release est inenvisageable, et les fichiers watch
> ne servent à rien dans ce cadre (uniquement).
Écoute, j'ai packagé des programmes (pas encore officiellement dans
Debian) dont les développeurs ne me tiennent pas au courant des
nouvelles versions, et n'ont pas de mailing-lists pour ça non plus. Je
dois donc une fois de temps en temps aller faire un tour sur la page web
(qui change souvent, et donc c'est difficile de s'y retrouver). Exemple:
EXACT.
> Mais je ne conteste pas l'intérêt des fichiers watch pour les
> "corner-cases", et les stats, etc. (tout ce que tu as mentionné plus
> haut).
> 
> > [..]
> 
> > > 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).
> 
> Oui... hélas...
Et que proposes-tu concrètement pour résoudre cela?
Je trouve personnellement que c'est un des apports majeurs de Debian au
Libre: ils testent, patchent, portent, ... toute une série de programmes
et resoumettent automatiquement leurs modifs.

> > > - 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.
> 
> Cela ne me semble pas justifier le fait qu'aucun de ces mainteneurs
> n'ait fournit pendant plusieurs mois les 20mn de travail à peine sur
> la version 1 Debian qui auraient corrigé des bugs sérieux, et pour
> lesquels il existait déjà un patch facilement applicable.
Peut-être que ça risquait de casser d'autres trucs?

> > > - 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.
> 
> Ok, tous les mainteneurs Debian sont au même niveau, et... quasi-parfaits.
> Au temps pour moi. ;-)
Ok, en fait, tu veux dire que, pour certains, même un package est de
trop? C'est ça? :-)

> > > - 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 pourquoi donc faut-il toujours un projet extérieur à Debian pour
> résoudre les problèmes qui devraient être résolus dans la Debian
> elle-même ?
Pour répondre à ta question: parce que Debian est avant tout une
plateforme stable pour développer des trucs. Si ça risque de casser ou
de changer des habitudes, ..., ça n'est pas intégré dans Debian
immédiatement, faut que ça fasse ses preuves d'abord (donc ailleurs). On
est dans le monde UNIX, ne l'oublie pas.

Je trouve que c'est un avantage de la GPL. Pense au fait qu'un projet
comme ça, fait sur base de FreeBSD ne serait probablement jamais
republié en libre.

> > [..]
> 
> > > > > > 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.
> 
> L'un n'exclut pas l'autre...
Tu es certain que tu sais ce qu'est un développeur? Certaines de mes
connaissances te diront sans hésiter que c'est plus proche de l'ours que
de l'être humain! ;-)
- ça fait peur
- c'est poilu
- ça sent pas bon
- impossible de comprendre ce qu'il dit
- c'est souvent gros
- ça ne se toujours un peu bizarrement

Évidemment, je ne pense pas ça moi-même...
Cependant, je ne vais pas écrire un démenti ici-même. :-D

> > [..]
> 
> > > > > 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?
> 
> Bah, rarissîme, et dans ce cas, rien ne devrait empêcher la
> compilation de l'outil de gestion de paquet sous Solaris.
Ça a l'air tellement facile quand tu le dis. :-)
D'abord, tu n'as aucun compilateur installé en standard, ...

-- 
Jérôme Warnier
Consultant
BeezNest
http://beeznest.net