[Linux-bruxelles] Debian or not debian

[Frederic Peters]

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.


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


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


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


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


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

Liste ?


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


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


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


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


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


        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