Re: [long] une idée pour faire avancer les choses
Raphael Hertzog écrivait:
> Il faut aussi prendre en compte que la multiplication des fichiers sur
> le miroir est problématique aussi (nombre d'inodes utilisés, rsync plus
> lent car plus de fichiers à traiter, ...).
« ma » solution créé une quarantaine de paquets supplémentaires pour
Debian. À moins que les .mo soit binairement dépendant d'une
architecture, on peut même les utiliser pour toutes les architectures
données. Dans le cas contraire, il faudrait utiliser les .po et faire
la manip que tu proposais plus haut.
Bref, 40 paquets supplémentaires à traiter pour Debian, ce n'est pas
monstrueux. Il doit y en entrer plus par mois dans unstable...
Par contre, le seul argument que j'ai trouvé opposable à ma solution
est celui de testing/unstable. Il est vrai que cela risque de créer un
gros trafic pour les mises à jour. Cela fera peut-être partie des
inconvénient d'utiliser quelque chose de non finalisée.
Pour le rsync, je suis d'accord. Mais il faudrait faire une étude
sérieuse avant de dire quelque chose. Si l'on regarde un peu les
choses de près, tous les paquets vont maigrir sérieusement (au moins
ceux qui sont i18n et l10n) et un paquet (enfin, une quarantaine...)
vont récupérer cet embonpoint. Statistiquement parlant, cela devrait
être identique...
Bon, personnellement, je ne sais pas ce qui se passe pour rsync en
interne (i.e. à savoir si c'est le nombre de fichier qui est coûteux
ou bien leur taille...).
>
> Bref, de toute façon, je ne crois pas à une solution universelle, elle
> ne résoud rien et apporte bien des inconvénients. Je préfère qu'on se
> concentre sur un problème précis et qu'on se débrouille avec une
> solution simple.
C'est sûr que si d'entrée tu n'en veux pas, on ne risque pas de
l'utiliser :-)
Plus sérieusement, résoudre au cas par cas les problèmes lorsqu'ils
arrivent n'est *jamais* la bonne solution¹ Aujourd'hui, le problème est
celui de la l10n des en-têtes... Demain, ce sera la l10n des
paquets... et des manuels... etc.
Faut pas croire mais lorsqu'un mainteneur aura une soixante de langues
à gérer pour les .mo, et qu'il aura quelques paquets à faire, il
pétera vite un plomb. Surtout un paquet qui bouge car bien activement
développé. La seule solution à ce moment sera d'avoir un mainteneur
quasiment à plein temps par paquet. Inenvisageable.
PK
¹: c'est ce que j'ai appris en travaillant. Tous les projets auxquels
j'ai participé et qui réglait localement les problèmes au fur et à
mesure qu'ils apparaissaient étaient ingérables rapidement.
--
|\ _,,,---,,_ Patrice KARATCHENTZEFF
ZZZzz /,`.-'`' -. ;-;;,_ mailto:p.karatchentzeff@free.fr
|,4- ) )-,_. ,\ ( `'-' http://p.karatchentzeff.free.fr
'---''(_/--' `-'\_)
Reply to: