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

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



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
indicative.

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.

I don't see that either of those predicate against a .tdeb extension
when .udeb exists for the same reasons.

> > > If you're only talking about the tdeb format per se, 
> > > I don't understand your reasoning.
> >
> > Other tools may need to support the locale roots in the .tdeb - these
> > changes will be easier if the tool can rely on these only existing in
> > a .tdeb instead of occurring in random .debs but not in others.
> >   
> But these locale roots would only exist in .tdeb-s. In .deb-s, there 
> wouldn't be such locale roots. If we're wondering whether we should 
> introduce a .tdeb format, we shouldn't reason that that there will be a 
> need for .tdeb if .tdeb is introduced.

Having .tdeb makes it simpler to handle TDebs on a variety of fronts
but I really don't think that a control field is comparable in terms of
functionality.

We have .udeb, .tdeb is sufficiently clear and aids the handling
of .tdeb by other packages - why restrict every operation to having to
inspect the DEBIAN/control file every time? `dpkg -f $file Languages`
is going to get tiresome every time, not to mention slow. (Package-Type
is just a different string for the same thing, except that will require
additional parsing for tdeb vs udeb.)

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgppIKxKl4nrz.pgp
Description: PGP signature


Reply to: