.tdeb format (DEP-4: The TDeb specification.)
> > Package management tools need a way to tell a .deb from a .tdeb - the > > two need to be handled differently by tools like dak, britney, apt, > > dpkg, reprepro, deb-gview and others. > Do you mean that package management tools need a way to tell a > traditional/current .deb from a package containing what the DEP proposes > to put in a .tdeb? 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. Say Translates: foo or, if Translates would only list the source package, Translation: Yes > 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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: .tdeb format (DEP-4: The TDeb specification.)
On Tue, 07 Apr 2009 10:23:37 -0400 Filipus Klutiero 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/ pgpyIJpOI03ny.pgp Description: PGP signature
Re: Re: .tdeb format (DEP-4: The TDeb specification.)
Neil Williams wrote: On Tue, 07 Apr 2009 10:23:37 -0400 Filipus Klutiero 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. 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. [...] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
