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:
pgp4qjR5xktDi.pgp
Description: PGP signature