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

Re: Re: .tdeb format (DEP-4: The TDeb specification.)

Neil Williams wrote:
On Tue, 07 Apr 2009 10:23:37 -0400
Filipus Klutiero <chealer@gmail.com> wrote:

> > In a similar way to udebs. The .tdeb needs to be handled differently by
> > package management tools (things like reprepro and dak) so that uploads
> > of TDebs can be made by translation teams, so that the existing source
> > package is not affected, so that TDeb uploads can more easily be made
> > during a release freeze without causing problems for archive management
> > software and without needing the tools to look inside the TDeb or rely
> > solely on a version suffix.
> > > Yes. I think a translation package could simply be identified by a > control field.

Then every file-based operation has to query the contents of the file
to know how to handle it. TDebs are sufficiently different internally
that other tools can handle them more easily if the filename is clearly

This is more important where there are lots of TDebs, so that is how
.tdeb came into the Specification. In Emdebian, a package can have
dozens of .tdeb files, obscuring the .deb files in a simple directory
listing. With the modifications for Debian TDebs after DebConf and the
resulting single TDeb per source package, this is not a problem for
archive listings but it could still be a problem for other tools.

> Say
> Translates: foo
> or, if Translates would only list the source package,
> Translation: Yes

I'm working on the patches for dpkg at the moment, I'm extending
Thomas' code to support 'dpkg -c' etc. and it is looking like a field
in DEBIAN/control will be necessary. I'm looking at putting a Languages:
field inside DEBIAN/control that lists the locale roots supported by
that TDeb. (The name of the field isn't material, Locale-roots: is more
accurate than Languages: but not as suitable IMHO.) This field will
be generated by dpkg-deb --tdeb -b so that it is always up to date.
However, if I find a better way of obtaining the data that can be
gleaned from using: `ar -t` with relevant parsing, then there will be no
need for the field, at least on the part of dpkg.

There is also a Package-Type: tdeb field which is used by
dpkg-genchanges in the same way as Package-Type: udeb is done currently.

Ah, I never heard about that. That sounds better than my suggestions.
I don't see that either of those predicate against a .tdeb extension
when .udeb exists for the same reasons.

Neither do I. I'm sorry if I've been unclear, but I never meant to say anything about the naming of translation deb files. I was only questioning the introduction of a new package format.


Reply to: