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

Re: Updating packages' l10n without risk (~unrelated to previous)



On Tue, Aug 26, 2003 at 12:12:07AM +0100, Andrew Suffield wrote:
> On Mon, Aug 25, 2003 at 10:27:44PM +0200, Martin Quinson wrote:
> > On Mon, Aug 25, 2003 at 11:10:06AM -0500, Adam Heath wrote:
> > > On Fri, 22 Aug 2003, Christian Perrier wrote:
> > > 
> > > > And, as Steve pointed out, translation stuff is minimalistically
> > > > invasive so this does not require an enormous amount of attention
> > > > after the NMU.
> > > 
> > > Yes, but there are new libraries that get linked to, new compilers, etc.
> > 
> > It should be possible to get the source, rebuild to needed mo files
> > (containing the translation in a compiled form), unpack the binary package,
> > add the mo file and repack the binary package, shoudn't it ?
> 
> It might be better to ask why we are shipping translations in the
> package at all, and figure out how to make it work with them split
> out. Our current infrastructure can't handle it, but it's probably
> possible to figure out something which can.

Well, people already sometime split the documentation out of the package, so
I guess there is no fundamental reason in dinstall, katie or other
maintainance script for not doing the same about languages.

But that would mean multiplying the number of packages by about:
 \times 3-10 for all languages
 \times 1.5 to split out the documentations which are not yet (plus separating
   the man pages useless on computational servers from the extra
   documentation)
 \times 3-10 again, to split the documentation depending on the language
 
And since dpkg is known for not scale well in number of packages in the DB
(#69192, #157060), the package management system would certainly explode.

There is some well known optimisation in the dpkg parser, and the dpkg team
is working on it: tuning (#74259, #139838, #160447, #206416), use of binary
DB when possible (#149760), use of a flex parser (#179296), and maybe others. 

Most of these bugs are taged patch, so there is nothing I can do as not dpkg
developper, beside praying every night that the real life of doogie and
wichert leave them more time (to look at those patch and tell us what does
not fit in them), and wait for better days. What I do quite happily.
   
Another interesting lead is the split of the status DB in several files. One
for the critical information, and others for the less critical ones
(description, ..). It was proposed back in august 2001, and I proposed my
help to propose a patch, once the dpkg maintainer explained to me how they
wanted to design the beast. A summary of this discution is at:
http://lists.debian.org/debian-devel/2001/debian-devel-200108/msg02193.html
(partial summary, since it's mine :)

Answer was in the spirit of:
http://lists.debian.org/debian-dpkg/2001/debian-dpkg-200109/msg00082.html

and I'm still waiting for the day where capable people will be given the
time to think about the design and inform me. But that's ok, I'm unable to
do what the dpkg team does, so how could I dare complaining?

> I don't have an interest in doing this, but somebody might.

I do :)


Thanks for your time, Mt.

-- 
No, I'm not going to explain it.
If you can't figure it out, you didn't want to know anyway...
   --- Larry Wall



Reply to: