On Mon, 06 Apr 2009 01:13:19 -0400 Filipus Klutiero <chealer@gmail.com> wrote: > > > > > 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 also involves separate handling for native vs non-native packages. The DEP does not require that - the +t1.diff.gz is used for native and non-native. Any changes to the .diff.gz (or .tar.gz for native packages) uploaded by the maintainer would require a source rebuild in order to maintain the integrity of the archive - that is precisely what the DEP is trying to avoid. You can't have a source package in a state that says "this isn't the source we actually used to build the binary". The source to build the .deb needs to be unchanged. The changes made to generate the .tdeb need to sit alongside the existing source package and have absolutely no effect on anything related to the binary packages or the source package uploaded by the maintainer. > > > > 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. > That can work, though I don't see what you were trying to say. That there should be no update to the .dsc because the existing source package must not be altered, therefore the second .dsc with the +t1 version suffix. In the case of a TDeb update during a release freeze, the .dsc signed by the maintainer is already part of testing so the TDeb upload to unstable must not change that .dsc. (Whether the +t1.dsc is retained is a different issue - I suspect that we only actually need to retain the +t1.diff.gz but as any .dsc is tiny, it isn't a big issue either way.) Note that many packages containing translatable content won't need a +t1.diff.gz at all, if the current version in testing was made after making a call for translations and waiting to receive updates before the upload (subject to RC bug fixes requiring a change during the freeze). The +t1.diff.gz is a way to introduce new translations and translation updates for packages that could not be translated prior to the maintainer upload of the original '+t0' TDeb which itself is described in the source package uploaded by the maintainer. Outside a release freeze, it will be up to debian-i18n to coordinate TDeb uploads for each source package amongst the translation teams and possibly with the maintainer to make arrangements such that translation updates can be uploaded in a collective manner (typically using a deadline of some sort) or as part of the next maintainer upload. Whilst the DEP supports +t[0-9], it is envisaged that the need for +t2 and +t3 etc. should be rare. > > 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. > Do you mean that package management tools need a way to tell a > traditional/current .deb from a package containing what the DEP proposes > to put in a .tdeb? In a similar way to udebs. The .tdeb needs to be handled differently by package management tools (things like reprepro and dak) so that uploads of TDebs can be made by translation teams, so that the existing source package is not affected, so that TDeb uploads can more easily be made during a release freeze without causing problems for archive management software and without needing the tools to look inside the TDeb or rely solely on a version suffix. udebs have different requirements for migration into testing (specific unblocks required with d-i approval), different locations under pool/main/ and different handling by archive software compared to standard .debs. TDebs have different requirements for migration into testing (TDebs migrate even if the package itself is frozen, as long as the version in testing matches that in unstable or the TDeb upload goes via testing-proposed-updates etc.), different handling by archive tools to retain the .diff.gz and the +t1.diff.gz and different upload restrictions. > If you're only talking about the tdeb format per se, > I don't understand your reasoning. Other tools may need to support the locale roots in the .tdeb - these changes will be easier if the tool can rely on these only existing in a .tdeb instead of occurring in random .debs but not in others. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpzQTV6qA1zB.pgp
Description: PGP signature