[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: DEP-4: The TDeb specification.

Neil Williams wrote:

------------------------------------------------------------------------
On Tue, 31 Mar 2009 13:06:35 -0400
Filipus Klutiero <chealer@gmail.com> wrote:

> Neil Williams wrote:
> > Primary Motivations (in order):
> >    1. Updates to translations should not require source NMU's.
> > > I guess that means avoiding to NMU with new diff.gz -s? If so, what are > the underlying motivations? 

To prevent translation updates (particularly debconf ones) from
interfering with existing transitions and release cycles. There is no
need to rebuild the source of the package merely to update or add a new
translation. The current barriers to such rebuilds can be overcome with
adapted tools, as described in the DEP.

http://dep.debian.net/deps/dep4/#index10h2

There is no good reason to permit translation updates to cause the
binary packages to be changed by recompiling the source. Dependency
versions change, new bugs can be introduced, existing transitions get
more complicated and the one time when translation updates are most
useful is during a release freeze when the binaries must not change.
The whole point of i18n (the process of making a package support
localisation by internationalising the codebase) is to ensure that the
same compiled binary can operate with any compatible translation. This
allows users to set LANG= and get the localised version at runtime.
Requiring that translations can only be added or updated in Debian by
recompiling the source is a complete waste of effort and is something
that gettext and other l10n middle-ware are expressly designed to
avoid. Debian, currently, is simply not getting the best out of l10n
and is making life difficult for everyone by putting the translated
files in the same packages as the compiled binaries. Each release
cycle, this comes back to bite us. TDebs will remove this burden.
That would be a nice improvement, but let me suggest another implementation. To avoid introducing a second diff, why not updating the regular diff (in the case of non-native packages) but indicating that the package shouldn't be entirely rebuilt when uploading? This seems simpler.
> What is the purpose of creating a new binary package format for this (as > opposed to reusing, say, the deb format)? 

To support easier management of the translations, including allowing
users to only install the translations that are needed for one
particular installation, instead of every user getting every
translation for every package they install, whether those translations
are even supported or not.
There are two ways to achieve this. One is per-language packages, the other is localization packages with multiple languages but using something like dpkg class support. Currently, the only way supported is language packages, but introducing a new package format will not necessarily allow the second way. Implementing this would take about the same amout of work as implementing something like dpkg class support for the deb file format. 
 The current model is based on server
installations where lots of locales may be configured to support
localisation of web content. Installing all 90 locales does not
translate well to desktop installations with only a handful of users
and maybe 5 or 6 languages. On a typical Debian box, /usr/share/locale/
takes up 250Mb when each language only requires a maximum of 9Mb.
I'm not sure why you write that the current model is based on server installations. The current "model" I see is just the "natural" state of things, with no modularization WRT translations in the vast majority of packages. But yeah, it would be great to save this space. 
TDebs are based on the .deb format, it is only a small change in the
organisation of the data.tar.gz but it simplifies various stages of
handling the resulting packages in the repository, in upload rules and
in other support tools.
Well, without details, I can't approve wholeheartedly, but if this isn't reinventing the wheel for no reason, the specification looks fine.
Reply to: