On Fri, 03 Apr 2009 16:45:46 -0400 Filipus Klutiero <chealer@gmail.com> wrote: Please note: All of the implementation details can wait until after Squeeze - all that is needed for this release cycle is that apt and dpkg can handle a migration from Squeeze to Squeeze+1 where packages being upgraded may use TDebs for the debconf translations. There's quite enough work there without trying to think beyond Squeeze into issues that may or may not arise around how the actual TDebs that won't exist until after Squeeze get handled by other tools not actually involved in allowing migrations from Squeeze to Squeeze+1. Please bear this in mind when discussing DEP-4 - I'll expand on the current Timeline section of the DEP to include some clearer indications of which stages get done when. (For those who want to know before I make the update, it will be based on the timescales from my presentation at Fosdem 2009, PDF and video available.) http://www.emdebian.org/media/debian-media/slides/TDebs_draft_specification/ http://www.emdebian.org/media/debian-media/ > > > 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. > Right - unless the .dsc is also updated. And if there is to be a tdiff, > I don't see why .dsc-s wouldn't include the tdiff's digest. There will be a complementary dsc using the +t1 version suffix. The .dsc uploaded by the maintainer cannot be updated without the maintainer signing it again. However, this is an implementation issue for after Squeeze. > > 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). > That's the question. I don't see why adding a new diff would ease > testing transition compared to updating the existing diff - given that > the "traditional"/current binary packages aren't rebuilt when uploading > translation updates. The existing diff is not to be changed because that makes it easier to be sure that we have the relevant source for the relevant binaries. ftp-master made it clear at DebConf8 that the source package (the .dsc, the .diff.gz and .orig.tar.gz or .tar.gz in the case of native packages) was not to be touched by a TDeb upload. Changes made to generate the TDeb go into +t1.diff.gz. Joerg? Mark? Do you want to add some comments on that? > > > > > 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. > > > Great. Then it should be little work to implement the same for .deb. 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. > > 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? > > > The data.tar.gz is correctly described, yes. The details I was referring > to are the simplifications of "various stages of handling the resulting > packages in the repository, in upload rules and in other support tools" > you were talking about. These details don't need to be part of the > specification, but could be somewhere in the DEP or in its presentation. Those are the bug reports that I need to start preparing but not until after Squeeze. ;-) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpGt4aOKi5Gn.pgp
Description: PGP signature