Hello,

On Sat, Jun 08, 2002 at 12:43:18AM +0200, Denis Barbier wrote:
> Salut,
> 
> on n'a actuellement pas de solution satisfaisante pour avoir les
> traductions (de programmes, de docs, ...) sans rendre le syst�me ob�se.
> Le programme localepurge permet de filtrer les locales non d�sir�s, mais
> cela n'est pas compl�tement satisfaisant, car
>  - on t�l�charge plein de choses qu'on met � la poubelle
>  - on ne peut pas rajouter des locales a posteriori
> 
> Une autre solution serait de cr�er un paquet par langue, mais cela
> rend la s�lection de paquets confuse par exc�s de paquets, et certains
> pensent que la multiplication des paquets va engendrer de gros probl�mes
> de performance pour dpkg.
> 
> Il me semble qu'un compromis serait d'avoir les paquets de traductions
> dans des arborescences s�par�es, p.ex.
>   deb ftp://ftp.debian.org/debian sid main contrib non-free
>   deb ftp://ftp.debian.org/debian sid/l10n/fr main contrib non-free
>   deb ftp://ftp.debian.org/debian sid/l10n/de main contrib non-free
> permettrait d'avoir les paquets usuels, plus les traductions en fran�ais
> et allemand.
> 
> Comme ces paquets sont en dehors de l'arborescence normale, cela va
> poser des probl�mes, par exemple l'utilisateur ne comprendra pas
> qu'il n'a pas acc�s � certains paquets s'il a oubli� de rajouter les
> lignes dans son sources.list. Il faudrait utiliser un nouveau champ
> dabs le fichier Packages, par exemple
>   Package: foo
>   Langs: foo-de, foo-es, foo-fr, foo-ja
> 
>   Package: foo-de
>   Depends: foo
> 
> etc. Les programmes de gestion de paquets pourraient sugg�rer (ou
> recommander) les paquets list�s dans le champ Langs, si la langue
> a �t� s�lectionn�e dans le sources.list
> 
> Est-ce que c'est une id�e r�alisable ? Y a-t-il des probl�mes qui m'ont
> �chapp� ?

Je pense que tout ceci est une id�e assez raisonnable. Personnellement,
j'appelle ca des atomes (au sens etymologique de non secable). Et c'est une
vieille id�e, il me semble qu'on en trouve les premieres r�f�rences sur
-devel en 99.

L'id�e, c'est que les metapaquets font des groupes de paquets, et les atomes
sont des parties de paquets installables ind�pendaments par dpkg.

Mais ca demande une modification assez profonde de dpkg (ajout de nouveaux
champs, pour dire que c'est pas un vrai paquet, mais un atome, et qu'il
"enhance" un autre en apportant telle ou telle langue, ou de la doc, etc).
Ca pr�supose une modification de la charte.
Ca pr�supose d'obtenir l'aval des developpeurs de dpkg.

A mon avis, avant que la base de donn�e dpkg (/var/lib/dpkg/status) ne soit
coup�e en morceaux (c'est pr�vu), c'est meme pas la peine d'en parler � qui
de droit, on va recevoir une fin de non recevoir du style "Ok, on y
r�fl�chira, et on vous recontactera".

M'enfin, je dis ca, moi, mais je dis rien.

Bye, Mt.

--- 
This message has been made up using recycled ideas and language constructs.
No tree has been cut nor animal harmed in process of making it.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


Répondre à