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

Re: DEP-4: The TDeb specification.



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


Reply to: