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

Re: Debian Debconf Translation proposal ( again )

On Wed, Jan 07, 2004 at 01:58:58PM +0100, Dominique Devriese wrote:
> Colin Watson writes:
> > I don't think this would be better. Ultimately, we have to get the
> > things to users, and our tried-and-tested means for doing so is
> > through .debs (not one .deb per little bit of text, one .deb per
> > *package*). The text in question is used when the .deb is being
> > configured, and therefore needs to be available at the right time;
> > if you propose any decoupling then you must consider dependencies,
> > and that turns into a nightmare very quickly. Let's keep it simple.
> I don't think you have correctly understood the proposed system.
> There would be one additional .deb per language, containing *all*
> translated debconf templates.  A user would install one or more when
> selecting installed languages in the install process, and they would
> remain available.  There is no problem at all with dependencies, and
> no abundance of new .debs.

There is most certainly a problem with dependencies: every time a string
changes the new package needs to depend on a suitably updated version of
the translations package, otherwise apt is perfectly within its rights
to install it later and so the translations will not be available at
configuration time.

In fact, there's an even worse problem: at the point when debconf
.config scripts are run, a package may rely only on essential packages
(and debconf itself). So I still don't think that having a separate
translations package will work. You might be able to kludge it up in the
installer, but it would break for upgrades. When you dist-upgrade from
sarge to sarge+1, the .config scripts of all upgraded debconf-using
packages will be run before *any* packages, including your proposed
translations packages, are installed. Thus, the translations will be

I urge you to reconsider this proposal, as I think it's fatally flawed.

> By the way, I urge you to also consider the general string freeze
> before a release as an important part of the proposal.

That seems plausible as part of a freeze. I haven't thought it out to
see whether I think it'd work in practice. (Most of my packages with
debconf translations have received fairly few translations anyway; only
the highest-profile of them stand any chance of staying remotely up to

Colin Watson                                  [cjwatson@flatline.org.uk]

Reply to: