On Mon, 13 Jun 2011 06:53:34 +0200 Guillem Jover <guillem@debian.org> wrote: > Hi Neil! > > I've just noticed you moved dpkg-gentdeb into /usr/bin/ from > /usr/share/embdebian-tools/ [0], and that you expect to merge that > command into dpkg-dev during this Debian release cycle. It's been a while since TDebs were discussed actively, I'm currently investigating the possible implementations. I don't mind delaying the move to /usr/bin but let's talk about how this is to be done because the release team, ftp-master and i18n teams agreed that TDebs are to arrive. > But the > implementation behind that command has never been discussed on this > list, True, I've only been playing with it again for the last few weeks and my own blog is the only place it's been outlined so far. I was half wondering if I should wait for more of the Multi-Arch stuff to get through the dpkg / apt updates before raising it here. I don't want to do anything with TDebs that ends up delaying Multi-Arch because I'm also trying to get Multi-Arch-Cross working. Equally, I am being nagged by the same people who want Multi-Arch delivered to get TDebs delivered in the same release cycle. ;-) > and I think I can speak for both Raphaël [1] and myself [2] > in that we are not really happy with the spec published [3] some > time ago. OK, let's revisit that spec - on this list. I won't move the commands just yet. Before I restart wider discussion about the spec on -devel and how things could proceed, I wanted to be sure that I had a sane implementation which could work for translators and maintainers. > IMO we're heading in the wrong direction by focussing only on translation > and by special casing everything to meet this expected usage. http://lists.debian.org/debian-dpkg/2008/12/msg00000.html I think there are a few things here: 0: The internals of how the "update" package is created need to be "update" specific. i.e. putting the relevant files into the relevant places beneath debian/tmp/ requires calls which are specific to the purpose of that update. These are the main changes in the dpkg-gentdeb script. Calls to msgfmt, lupdate, po4a-build, po2debconf etc. 1: How dpkg is then used to create the "update" package, how dpkg-source is used to create the "update" source changes and - especially - how dpkg handles applying the update changes over the top of the downloaded source and how maintainers get the update into their packaging VCS are common to however the update is managed. 2: Update packages other than TDebs need to be agreed with ftp-master and I have seen no indication that this has been done. 3: Current agreement with ftp-master is that a translation update *must not have to go through NEW*. This is my biggest problem with the partial package route. TDebs need to be initially prepared by the maintainer as a normal package and dpkg-gentdeb / dh_gentdeb can then be added as a permanent change in debian/rules (or via other build systems etc.) The update of that TDeb is then much less disruptive because the archive already contains the equivalent of a +t0 TDeb. These packages should not be invisible to the PTS, DDPO, packages.d.o or the apt cache. As such, these packages must exist in the normal run of ftp-master and this, to me at least, mandates that the TDeb must already have been created by the maintainer before a TDeb update can be uploaded. Initially, therefore, the translation updates for Wheezy may well involve some NMU's to implement TDeb support but hopefully this can be done early in the cycle and, for Wheezy, will solely focus on the debconf templates. i.e. the first round of TDebs will "appear empty" to dpkg -c. 4: TDebs are NOT rebuilds - there would be no compiling. This is fundamental to current ftp-master agreement. The whole point is to avoid the NMU route with it's knock-on effects on the release team migrations and binary rebuilds. This is a clear difference compared to security updates and other use cases for partial debs. Security updates, in particular, can require changes to the dependencies, changes to runtime behaviour of compiled binaries, changes to configuration in /etc/ and other changes. None of these are allowable for a TDeb. 5: TDeb updates are simply created by the "translation coordinator" by calling the dpkg-gentdeb script directly with a -t argument (or whatever other syntax is agreed). This step does not require dpkg-buildpackage, does not require build dependencies installed - not even for the clean target, only dh_clean is called. The TDeb generation cleans up after itself using internal rules, specific to the update in hand, and does *not* currently expect to be run in any VCS type environment. i.e. the translation coordinator simply does apt-get source, replace the various PO files and other translation data, calls dpkg-gentdeb -t, gets a .changes file, a +t1 .diff.gz or debian.tar.gz and a +t1_all.tdeb which can be uploaded without *any* effect on the release team. Quite similar to current NMU methods. 6: TDebs have another peculiar interaction with dpkg via their principle role in Wheezy - debconf updates. The DEBIAN/templates file will need to live in the TDeb (uploaded by the maintainer) and this will require special processing by dpkg (and apt) so that the templates are located correctly and either presented as package.templates or handled as package-tdeb.templates. I think we need a wiki page to try and sort these things out, we also need to get together at DebConf. The DEP mechanism being broken, I'll see about updating the current wiki page: http://wiki.debian.org/i18n/TranslationDebs -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgp9CxWJ1Yxb0.pgp
Description: PGP signature