On Fri, 03 Apr 2009 04:21:59 -0400 Filipus Klutiero <chealer@gmail.com> wrote: > That would be a nice improvement, but let me suggest another > implementation. To avoid introducing a second diff, why not updating the > regular diff (in the case of non-native packages) but indicating that > the package shouldn't be entirely rebuilt when uploading? This seems > simpler. That breaks the existing source package in Debian - the .dsc referring to that .diff.gz has been signed by the maintainer and any changes will break that signature. TDebs are not related to source changes and should not affect the existing source package. A TDeb upload needs to sit alongside the existing files in the archive, not replace files uploaded by the maintainer. This allows TDeb uploads during a release freeze - even very late in a release cycle (which is the very time that many debconf translations get updated currently). > > > What is the purpose of creating a new binary package format for this (as > > > opposed to reusing, say, the deb format)? > > > > To support easier management of the translations, including allowing > > users to only install the translations that are needed for one > > particular installation, instead of every user getting every > > translation for every package they install, whether those translations > > are even supported or not. > There are two ways to achieve this. One is per-language packages, the > other is localization packages with multiple languages but using > something like dpkg class support. Currently, the only way supported is > language packages, but introducing a new package format will not > necessarily allow the second way. Implementing this would take about the > same amout of work as implementing something like dpkg class support for > the deb file format. ? It's already implemented via a patch devised by Thomas Viehmann. Sadly, due to other pressures, his tree on git.debian.org has been removed. > > TDebs are based on the .deb format, it is only a small change in the > > organisation of the data.tar.gz but it simplifies various stages of > > handling the resulting packages in the repository, in upload rules and > > in other support tools. > Well, without details, I can't approve wholeheartedly, but if this isn't > reinventing the wheel for no reason, the specification looks fine. The DEP does describe the organisation of the data.tar.gz: http://dep.debian.net/deps/dep4/#index5h2 Which details are missing from the DEP? If you're actually asking to see the code, the changes were also put into http://git.debian.org/?p=users/codehelp/dpkg.git;a=summary However, I'm useless with git and my git 'thing' appears broken as far as I can tell. I can't see how or why or how to fix it, so I'll update the TDeb changes to the latest dpkg source next weekend and just stick with patches or subversion - at least that works. (Please, git-fanboys, don't start a sub-thread/flamewar abusing me for my obvious idiocy in being unable to comprehend git - I hate it, I apparently can't use it and I would simply prefer to actually get things done without having to fight it.) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpFT2BIG70oT.pgp
Description: PGP signature