[Linux-bruxelles] Debian or not debian

[Hervé Eychenne]

On Wed, Jun 09, 2004 at 06:54:14PM +0200, Frederic Peters wrote:

> Hervé Eychenne écrivait :

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

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

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

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

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

> Non.  La perception des NMU a évolué ces derniers mois et les
> mainteneurs les considérant comme des agressions diminuent.  Ce n'est
> pas non plus un constat d'échec, je suis très heureux qu'il y ait des
> NMU de certains de mes paquets quand je n'avais pas le temps de m'en
> occuper.

Il serait intéressant d'avoir des stats sur les NMUs.

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

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

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

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

Selon moi, prendre la responsabilité d'un paquet et ne pas remplir
sa fonction est une chose plus grave que prendre la décision de refiler
le paquet à quelqu'un de plus consciencieux ou actif.

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

> Pas très éloignés mais avec des différences fondamentales dans la
> gestion des dépendances.

Et nous sommes tous d'accord pour dire qu'elles sont bien mieux gérées
par Debian.

> > Or il manque tellement de choses... tellement.

> Liste ?

Olalala... si tu as quelques heures devant toi... ;-)
Je vais faire un document là-dessus, et j'en donnerai la référence dans
quelques temps, ok ?

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

> La rotation des fichiers de log.  Ce n'est pas essentiel.  C'est bien.

Si, il est essentiel que cela soit géré au niveau de la distribution
(unicité), comme ça tous les packages qui le souhaitent peuvent en
bénéficier. Les applis qui le souhaitent peuvent gérer ça par
elles-mêmes.
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).»

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

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

> > > 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 parfois ça ne suffit pas pour avoir une intégration correcte.
> D'où l'illusion de ton monde idéal où il n'y aurait pas de travail de
> packaging à faire.

Je n'ai jamais dit qu'il n'y aurait aucun travail de packaging à
faire. Je pense juste que pour 90% des cas, on pourrait factoriser un
maximum de trucs dans les autotools. Je n'ai pas dit tout, et pour
tout. Mais ça serait déjà un grand pas.

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

> J'ai voulu télécharger authconfig tout à l'heure.  Les sources sont
> dans un .srpm.  J'aurais préféré ne pas avoir en plus à télécharger
> rpm2cpio pour sortir le .tar.gz qui y était contenu.

Tout simplement parce que la commande de gestion de package (rpm, ici)
ne semble pas te permettre d'extraire les fichiers contenus dans un
package. Alors qu'il le devrait (et dpkg le fait).

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

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

> Bon sommeil ?

Sans doute. La douce torpeur a des côtés séduisants, mais je la
laisse à d'autres. :-)

 Hervé

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