[Linux-bruxelles] Debian or not debian

[Hervé Eychenne]

On Thu, Jun 10, 2004 at 11:29:39PM +0200, Ludovic Brenta wrote:

> > Je sens poindre le reproche... "arrête de critiquer et fais quelque
> > chose".
> > N'étant pas développeur Debian, je fais ce que je peux. :-)
> > Et je me démène déjà pas mal, croyez-moi.

> Moi non plus, je ne suis pas développeur Debian.  Pourtant j'ai 18
> paquets sous ma responsabilité.

C'est-à-dire ? (ça m'intéresse)
Comment peut-on avoir des paquets sous sa responsabilité
(qu'entends-tu par là exactement ?) sans être enregistré comme
développeur Debian ?

> > Seulement, j'ai l'impression de passer ma vie à me battre avec des
> > mainteneurs Debian. Car toute discussion avec eux débouche
> > quasi-invariablement sur l'un des arguments suivants (parfois
> > dans l'ordre, au fur et à mesure que la discussion avance et que je
> > réfute leurs arguments) :

> En tant que responsable de paquets, il m'est arrivé de répondre de la
> sorte, mais avec des nuances:

Je joins des exemples concrets.

> > - ça marche très bien comme ça pour moi (égoïsme)

> Je ne peux pas reproduire le bogue, donc je ne peux pas le corriger.
> Pas égoïste, mais sincèrement désolé.

Je faisais remarquer a Matt Zimmermann, qui s'occupe notamment des alertes
sécurité Debian, qu'il était parfaitement anormal qu'un nouveau paquet
unstable ou testing corrigeant une vulnérabilité (à défaut d'alerte
officielle) n'ait pas un urgency à high. Car si vous regardez
bien, rien de garantit qu'il ne sera pas mis à low, vu que cela dépend
du bon vouloir et du bon sens de celui qui l'uploade.
Réponse Debian formattée (et donc stupide) de l'intéressé : "Si tu veux de
la sécu, utilise stable".
Je lui dis que je ne _peux_ pas utiliser woody, car bon nombre de
paquets vitaux pour moi sont trop anciens et n'ont pas les
fonctionnalités dont j'ai besoin.
Il me dit que je n'ai qu'à utiliser testing, et faire des upgrade tous
les jours, que ça marche très bien pour lui comme ça (excuse no1).
Je lui dis que je n'ai pas le temps de faire des upgrades
tous les jours, que ça a déjà cassé ma machine une fois et que je
peux difficilement me le permettre, et que ma ligne est de toute façon
trop lente pour cela.
Je lui dis que ne mettre à jour que les paquets ayant une urgency à
high (en admettant que cette valeur soit correctement positionnée,
bien sûr) serait un bon compromis pour moi, et je rajoute qu'il n'est
d'ailleurs pas normal qu'il faille télécharger un paquet pour avoir
accès au changelog et au flag urgency. La discussion dérive sur la
lourdeur de dpkg, de la soi-disant l'impossibilité de rajouter quelque
attribut que ce soit dans le fichier Packages, etc... et il en arrive
évidemment à l'excuse no3 (cela ne doit pas être fait).
Sentant l'impasse, je reviens sur le fait de mettre au moins dans un
document Debian officiel que le flag urgency doit être mis à high pour
les nouveaux paquets corrigeant une vulnérabilité.
Il me redit que mon cas est bâtard (excuse 1), qu'il ne voit pas l'intérêt
(excuse 2 et 3) et que je peux toujours le proposer sur debian-devel
(excuse 4).

> > - cela n'est pas nécessaire (manque d'exigence)

> Manque d'exigence?  Moi vivant, jamais! :) Mais si "cela" est déjà
> fourni par un autre paquet?

Alors il faut extraire ce qui est commun au deux (pour peu que ce soit
assez gros) et que les deux (ou plus) utilisent le même mécanisme.

> > - cela ne doit pas être fait (courte vue, immobilisme)

> "Cela" introduit un bogue ou un grave problème de maintenance.  La
> courte vue vient de l'utilisateur.

Merci pour moi... ;-)
Ok, autre exemple. Théodore Ts'o (non des moindres, pourtant), auteur
et mainteneur des outils ext2 et ext3.
Je fais remarquer qu'il serait bon que l'on puisse faire en sorte dans
certains cas de s'assurer avec certitude qu'un fsck périodique n'aura
pas lieu au prochain reboot, car cela peut être très long et très
gênant si on a des contraintes de temps de boot et de disponibilité.
De plus, cela peut aussi être intéressant si on boote un portable hors
secteur et qu'on ne veut pas user sa batterie inutilement.
Il me répond qu'il vient d'introduire dans fsck.ext2 un mécanisme qui
permet de retarder le fsck périodique pour un portable hors secteur.
J'aurai beau lui faire remarquer qu'il n'existe toujours pas de moyen
de s'assurer qu'un fsck périodique n'aura pas lieu au prochain reboot
(portable ou pas), il me répondra : ce que j'ai fait me semble
suffisant (excuse no 1 et 2).
Je lui réponds au passage que je ne comprends pas pourquoi il y a des
fonctionnalités de fsck équivalentes pour chaque système de fichiers (fs)
qui se retrouvent sous des options différentes dans les "drivers"
fsck.fs1 et fsck.fs2, et parfois même pas du tout dans un fsck.fs3.
Il me répond qu'il n'y a aucun moyen de garantir cela, vu la façon
dont chacun des drivers est maintenu de façon découplée des autres,
que ce n'est pas grave (excuse no1, 2), et que ça risquerait même de
créer des problèmes (excuse no 3). (ce qui est vrai vu la façon dont
c'est géré actuellement, mais n'envisage même pas que cela pourrait
être mieux géré)

> > - si tu en as vraiment besoin, fais-le toi-même (bottage en touche)

> Je n'ai pas le temps (par exemple, de prendre en charge PolyORB, ou de
> corriger tous les bogues de GNAT).

<troll>Extrait de la Debian Policy : tout développeur Debian ayant déjà
épuisé les excuses no1,2 et 3 et étant à cours d'arguments valables
au bout de 5 ou 6 allers-retours de mails pourra sortir le joker no4.
</troll>
:-)

 Hervé

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