tdiff (DEP-4: The TDeb specification.)
Neil Williams wrote:
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.
Yes, but the source package contains more than the source used to build
the "traditional" binary packages. It also contains (potentially) source
for translation debs. As long as the only source changed is the source
for the translation debs, the "traditional" binary packages don't need
to be rebuilt.
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.
Per what I wrote above, I don't see anything preventing the source
changes for translation debs to be integrated in the traditional diff
(again, in the case of non-native packages).
> > > > 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.
I don't see a problem preventing the traditional .dsc to be changed.
Changing the .dsc does not imply that the existing source package must
be altered. The .dsc could be updated in testing.
(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.)
I think it should be retained; small issue, indeed.
To sum up, I still don't see anything that imposes introducing a tdiff,
even to avoid rebuilding the traditional binary packages. But, I'm
starting to see tdiff is probably a good idea anyway for security reasons.
Reply to: