Moving dpkg-gentdeb into /usr/bin/
On Mon, 13 Jun 2011 06:53:34 +0200
Guillem Jover <firstname.lastname@example.org> wrote:
> Hi Neil!
> I've just noticed you moved dpkg-gentdeb into /usr/bin/ from
> /usr/share/embdebian-tools/ , 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
> But the
> implementation behind that command has never been discussed on this
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  and myself 
> in that we are not really happy with the spec published  some
> time ago.
OK, let's revisit that spec - on this list. I won't move the commands
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.
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: