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:
pgpZGKnOkWgdA.pgp
Description: PGP signature