Please use alternative dependency to belocs-locales-data

[Denis Barbier]

Hi,

here is a bugreport as discussed at rosetta-users. I will not follow up
to this list since this discussion is not related to Rosetta.

I am reluctant to ship install-language-locales and remove-language-locales
in belocs-locales-data, because these scripts are meant to be called by
maintainer scripts and Debian users will ask why they are there if no scripts
call them.

I considered many other options, and believe that language packs could run
these scripts only if they are available. People who want to install
belocs-locales-data should then run locale-gen by hand after installing
language-packs, but it is likely that they already generated their locale
when configuring b-l-d.
IMO this is much better for them than the current situation, and they can
understand that language packs are primarily supported with the locales
package, and installing b-l-d may have some drawbacks.

PS: when playing with these scripts, I found funny that remove-language-locales
takes much more time than install-language-locales :)

[Martin Pitt (pitti)]

(In reply to comment #0)

> I am reluctant to ship install-language-locales and remove-language-locales
> in belocs-locales-data, because these scripts are meant to be called by
> maintainer scripts and Debian users will ask why they are there if no scripts
> call them.

I would be fine with moving them to a less visible place in /usr/share/, or just
fork the Debian version (although that creates manual work again).

> I considered many other options, and believe that language packs could run
> these scripts only if they are available. People who want to install
> belocs-locales-data should then run locale-gen by hand after installing
> language-packs, but it is likely that they already generated their locale
> when configuring b-l-d.

I would prefer if locales would work after language pack installation regardless
of whether you use belocs or glibc locales. We can agree to a common path for
the scrips in both packages, or even ship the scripts in an entirely different
package, provided that belocs is 100% compatible to the glibc locales
(/etc/locale.gen etc.).

> IMO this is much better for them than the current situation, and they can
> understand that language packs are primarily supported with the locales
> package, and installing b-l-d may have some drawbacks.

Right, I can add an alternative dependency to belocs-locale-data and test for
the install-language-locales script before calling it, no problem. So we have at
least something working in Breezy. However, I don't see why it should be hard to
make belocs fully work in Breezy by adapting the scripts to it?

> PS: when playing with these scripts, I found funny that remove-language-locales
> takes much more time than install-language-locales :)

Because install- uses --keep-existing, but that switch does not remove obsolete
locales, so you have to rebuild all locales from scratch when you remove some.

[Denis Barbier (barbier)]

> I would prefer if locales would work after language pack installation
> regardless of whether you use belocs or glibc locales. We can agree to a
> common path for the scrips in both packages, or even ship the scripts in
> an entirely different package, provided that belocs is 100% compatible
> to the glibc locales (/etc/locale.gen etc.).

I am definitely willing to be 100% compatible with locales, so if you
can put your scripts into another package, that is fine.

> Right, I can add an alternative dependency to belocs-locale-data

No need to add this dependency, b-l-d Provides: locales. There was
a problem because of the _versioned_ dependency, hence the original
subject ;)

> and test for the install-language-locales script before calling it, no
> problem. So we have at least something working in Breezy. However, I
> don't see why it should be hard to make belocs fully work in Breezy by
> adapting the scripts to it?

Your scripts work just fine with b-l-d.

[Martin Pitt (pitti)]

 belocs-locales-data (2.3.4-16ubuntu1) breezy; urgency=low
 .
   * Ship {install,remove}-language-locales to be fully compatible to "locales"
     and to provide a working alternative dependency for the language packs.
     (Ubuntu #15541)

This provides the necessary foundation.

[Martin Pitt (pitti)]

In langpack-o-matic I did the following change of the language-pack-*-base
dependencies:

-Depends: locales (>= 2.3.2.ds1-20ubuntu3), language-pack-%PKGNAME% (>=
${Source-Version})
+Depends: locales (>= 2.3.2.ds1-20ubuntu3) | belocs-locales-data (>=
2.3.4-16ubuntu1), language-pack-%PKGNAME% (>= ${Source-Version})

With this, you can use belocs without any trouble any more.

This solution is still a bit ugly, but will have to do for Breezy. In Dapper, we
(hopefully) fully switch to belocs.

I will build new language packs soon, so that the change becomes effective in
the packages.

[Martin Pitt (pitti)]

(In reply to comment #4)

> I will build new language packs soon, so that the change becomes effective in
> the packages.

This happened now, they work fine with belocs now.