[Linux-bruxelles] Debian or not debian

[Frederic Peters]

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 ?


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


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


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


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

Ok; mais j'ai aussi une liste perso, dont je devrais arriver à barrer
un point rapidement (avec annonce ici).


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


> > 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.
Idéalement, il n'y aurait rien à faire.  Mais il faut intégrer
correctement et ça nécessite souvent des modifications.


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

Même si je suis d'accord avec Dany (qu'autotools prend parfois la
tête), je trouve qu'ils apportent effectivement un grand plus dans la
vie du mainteneur. (qui n'a plus à se taper des Makefile mal écrits).


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


        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