[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DEP-4: The TDeb specification.



On Wed, 18 Mar 2009 00:26:30 -0500
Manoj Srivastava <srivasta@debian.org> wrote:

> On Tue, Mar 17 2009, Neil Williams wrote:
> 
> >>  Do you prevent mixing old and new .debs and .tdebs?
> >
> > Changes to translations use +t1.diff.gz etc.
> >
> >>  How do you merge data from a new package into the tdeb data?
> >
> > The real question is how to get apt to understand getting the
> > +t1.diff.gz when asked for apt-get source and for dpkg to expect to
> > unpack +t1.diff.gz etc.
> 
>         Also, currently one may put up a new version of a package into
>  experimental or people.debian.org; and it carries with it the older
>  translations. If the translations are separated, then the people.d.o
>  package will be useful only for testing by the speakers of the original
>  langiage the debconf templates were written in.  This seems like a step
>  back

No, the initial TDeb will be generated by the maintainer, effectively
+t0, so the maintainer uploads the initial TDeb containing whatever
translations are currently supported, putting the TDeb wherever you
put the binary and .dsc. It is up to the maintainer to incorporate any
+t1.diff.gz containing updated or new translations that may exist
already into each new Debian version. The other repository could also
simply copy any existing TDeb that does already exist alongside the test
package. (Being Arch:all, the TDeb is only included in the maintainer
upload or subsequent translator updates, buildd's don't need to worry
about TDebs at all.)

If the new version has changed translated strings then those will only
available in English until the +t1 TDeb arrives anyway - that doesn't
change. (English is always the language in which the templates must be
written initially - en_US at that.) There remains the current advice
that changes to the templates should always seek translation updates
prior to the upload of the initial TDeb by the maintainer. If
maintainers implement a string freeze and wait for translation updates
before uploading, the chances of a +t1.diff.gz being required by time
of the next release by the maintainer are lower.

Just like the dependencies of a package in experimental, the TDeb is
still available and can be updated by translators, the +t1.diff.gz is
available to the maintainer to incorporate into any new version and
debian/rules needs to include support for generating the TDeb for each
new version.

Maintainers will be creating TDebs in Squeeze+1, using debian/rules,
using debhelper calls and uploading TDebs each time they would
currently upload any package that contains /usr/share/locale/LC_*/ etc.
Those TDebs are, effectively, +t0 - only updates by translators start
the +t1 sequence.

Maintainer uploads:
foo_1.2.3-4_amd64.deb
foo-tdeb_1.2.3-4_all.tdeb
foo-bar_1.2.3-4_amd64.deb
foo_1.2.3-4.diff.gz
foo_1.2.3.orig.tar.gz
foo_1.2.3-4.dsc
foo_1.2.3-4_amd64.changes

The foo-tdeb package will be listed in the .changes anyway so existing
tools will simply add it to the list of files to be uploaded to
ftp-master or wherever. foo-tdeb_1.2.3-4_all.tdeb is, effectively,
foo-tdeb_1.2.3-4+t0_all.tdeb

Translator updates arrive:
foo-tdeb_1.2.3-4+t1_all.tdeb
foo_1.2.3-4+t1.diff.gz
foo_1.2.3-4+t1.dsc
foo_1.2.3-4+t1_all.changes

Maintainer makes a new release foo_1.2.3-5 which incorporates the TDeb
changes in a similar manner to how an NMU is included today. All files
matching foo*1.2.3-4* are removed by dak when the new version is
uploaded. The updated translations now exist in
foo-tdeb_1.2.3-5_all.tdeb - uploaded by the maintainer and there is no
+t1.diff.gz or +t1_all.tdeb until the package translations need to be
touched again.

The key point is that a +t1 revision can happen *during a release
freeze* without touching the source, without changing any of the
binaries. Once the release is out and unstable is accessible again, the
maintainer adds +t1.diff.gz to their next upload. Done.

(Interesting point, if the current Debian version has already migrated
to testing, the +t1 TDeb will also need to migrate with the +t1.diff.gz
as source. Whether the rules should change for a TDeb migration needs
to be decided - it could be that TDebs have a shorter time in unstable
if the relevant version of the package is already in testing or even
be allowed to migrate immediately. That's all for Squeeze+1.)

The system is quite similar to how an NMU is currently done - without
the problems of a source rebuild - and maintainers can handle the +t1
in much the same manner to fit into their workflow. Whether a changelog
entry is needed is undecided, it would be courteous but not necessarily
mandatory, especially if no bug exists to be closed.

What remains to be resolved is how best to fit that
"maintainer incorporates the changes from the TDeb" stage is handled so
that it doesn't disturb maintainer workflow too much. The changes will
only be in the po/ files and consist of simply unpacking the
+t1.diff.gz on top of your existing checkout (and committing any
changes if you use an RCS).

None of this happens until Squeeze+1.

There is no particular need for any of these stages to require bugs to
be filed or closed, unless maintainers feel that this would be the best
way to be notified. We could have something like the lowNMU system to
indicate packages where translations can be updated without needing
bugs to be opened or closed. (maybe noTBUG). This allows more automation
on the translator side.

The implementation is being staggered - all packages using debconf first
(Squeeze +1), native packages containing gettext translations second
(Squeeze +1, possibly into Squeeze +2), non-native packages with the
Debian maintainer upstream next, finally moving on to the remainder.

If you don't use debconf and your packages do not handle .debs
directly (like apt or dpkg or reprepro), there is nothing that needs to
be done in your packages until Squeeze+2.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgp10P43kaHAW.pgp
Description: PGP signature


Reply to: