Thoughts about separating language packs

Martin Pitt martin.pitt at
Fri Nov 5 06:51:52 CST 2004


Since Matt and Scott have the same question, I took the liberty to
slightly reorder the paragraphs.

Matt Zimmerman [2004-11-04 16:01 -0800]:
> An Ubuntu-specific build system is not a problem, but what are you
> proposing?  That if a user builds a package from source, the localisations
> are thrown away?  Or that users will be required to rebuild the language
> pack?
> Note that users will sometimes build a newer version of a package from
> source (i.e., one newer than their language pack).

Scott James Remnant [2004-11-05 11:16 +0000]:
> What happens when the user builds a package from source themselves?
> Should the translations in their source package be thrown away in favour
> of the language pack, if not how do we resolve the "Replaces:
> language-pack" issue?

It is possible to put the generated translations into a place where a future
build of the language pack can pick them up. However, this can cause all kinds
of weird screwups, up to the point of security problems.

The simplest and most robust solution is to just throw them away, and in the
interest of not breaking too much, I believe this is the way to go if we have
language packs.

Matt Zimmerman [2004-11-04 16:01 -0800]:
> This brings about another question: how do we ensure that the language pack
> is in sync with the application package?  The only solution which comes to
> mind involves a _very_ large Provides: line in the language pack. :-)

I do not know a perfect solution to this. Technically, the language
pack depends on a particular version of each binary package, and each
binary package depends on a matching language pack. This is naturally
fragile.  A particular package version and the matching translations
intrinsically belong together, so I do not promise that tearing them
apart will be easy.

Building the language pack after all other packages have been built
(right before release) should solve that, though.

Scott James Remnant [2004-11-05 11:16 +0000]:
> > We currently have 1047 source packages, but as much as 265 do not use
> > debhelper. Although a debhelper hook would be easier, it would miss
> > about a quarter of our source packages, which is not acceptable.
> > 
> Where do you get that quarter figure from?  By my quick
> finger-in-the-air guess, nearly all of the packages in main use
> debhelper.

$ grep ^Package: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_hoary_main_source_Sources | wc -l

$ grep-dctrl -s Package -FBuild-Depends debhelper /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_hoary_main_source_Sources |wc -l

$ echo "(1050-767)/1050" | bc -l

Three more source packages in two days. Hoary evolves :-)

> If you want certain files to not be placed in the package, you take them
> out (or don't put them in) in debian/rules.  Either add a call to
> something that extracts the translations, or modify debhelper and
> friends to do the extraction for you.

See above, debhelper will not catch more than a quarter of our source packages.
Call me lazy, but I don't want to modify some 250 packages just for inserting
one and the same command over and over again, or convert them to debhelper. As
soon as we want to use a different approach, we have to change all packages
again, and we have to drag these modifications through all syncs.

I believe in general solutions for general problems, so if we don't modify
dpkg, then the task of extracting gettext templates becomes utterly huge (and
utterly boring as well).

Again, personally I do not think that language packs are a good
solution which is easy to implement. But as it stands, it is a Hoary
feature goal, and I was asked to think about it.

Maybe the proposed solution tries to solve too much, and we should
modify our Hoary release goal a bit. As far as I understand, the
current problem is that after installation, certain packages like
OO.o, Mozilla, Firefox etc. are not localized because their language
debs are missing. Since this problem is actually orthogonal to the
gettext extraction, an (IMHO) sane compomise would be to create
language packs only for these problematic applications, rather than
for the full archive. This would avoid all these hacks and problems
and solve our actual problem as well.

Have a nice day,

Martin Pitt             
Ubuntu Developer  
Debian GNU/Linux Developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :

More information about the ubuntu-devel mailing list