Re: Changes to rpmstrate (or localedrake?) for zh_TW

Kaixo!

On Mon, Feb 12, 2007 at 02:13:46PM +0100, Pixel wrote:

> > So the behaviour should be changed to:
> >
> > * for each requested language do:
> > 	* look at its LANGUAGE variable, and install packages for
> > 	  the first matching locale (it may be different locales for
> > 	  different packages)
> 
> currently it's not done that way at all, since it can't work for
> mozilla-firefox-*. we do:
> 
> for each package do:
>    * if it requires locales-xxx, select it iff that locales is
>    selected

A possible solution could maybe be to split locales packages
for some languages (zh_CN/zh_TW, pt_BR/pt, nn/nb);
however, as the list of installed locales is computed from the LANGUAGE
variable, there should be a special rule to not install the other
locales-* variant (maybe it could be chosen during install,
eg: "Install all language variants (uses more disk space)? (Y/n)"

> we'll have to change one day, so that rpmsrate format can be
> simplified and get rid of clean-rpmsrate. for this, virtual provides
> must be added, even for things like mozilla-firefox-* which do not
> have a main package, only l10n packages (kde-i18n-*, koffice-i18n-*,
> koffice-l10n-* already have a provide)

You mean something like "Provides: l10n-zh_CN"
and request all packages with such a provides to know what is
installable for that locale?

But that doesn't solve the problem; the problem is not knowing what
could be installed, but the fact that in some cases, there may be two
or more localizations, but the user only wants one.

for example, when choosing pt locale, the LANGUAGE variable tells
LANGUAGE="pt_PT:pt:pt_BR"
that is, what is wanted is to use the "pt_PT" localization if it
existis, if not, then the "pt" one, if not then the "pt_BR" one.
But what if there exists "pt_PT" (or "pt") as well as "pt_BR"?
Currently both are installed, but the user will only use one, meaning
a waste of disk space.
The problem is that we cannot simply discard pt_BR localization,
because in some cases there is not pt_PT (or pt) one.

A possibility would be to displace the burdening to package mantainers
instead of drakx/rpmdrake mantainers; so if there is only a pt_BR
localization, have something like:
	# also provide l10n-pt untill there is a real pt package,
	# for fallback compatibility
	Provides: l10n-pt_BR, l10n-pt

and we could use the %_install_langs macro (in /etc/rpm/macros) to know
which locales are needed (that macro can have the special value "all").

it would require splitting a few locales-* rpm packages, and having
"provides: l10n-xx" in all language specific packages.

that provides-oriented approach would allow a package providing support
for two or more locales (like the above exemple with pt_BR and pt)
while the current requires-oriented approach doesn't (well, it could,
but it would require installing *all* the required locales, not just
one; that is btw the main reason why the split of the chinese,
portuguese and norwegian locales-* hasn't been done, because it would
be useless, as it wouldn't change the package selection.


-- 
Ki ça vos våye bén,
Pablo Saratxaga

http://chanae.walon.org/pablo/		PGP Key available, key ID: 0xD9B85466
[you can write me in Walloon, Spanish, French, English, Catalan or Esperanto]
[min povas skribi en valona, esperanta, angla aux latinidaj lingvoj]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFF0HG1pSX1mtm4VGYRAt1tAKCMtvwVGOhe3xaHt0Sop5LW/1ZwjQCcChDl
YAa8X2Qbnc/+k6NfzcBUVkQ=
=ViFV
-----END PGP SIGNATURE-----