Re: Re: tdiff (DEP-4: The TDeb specification.)
------------------------------------------------------------------------
On Tue, 07 Apr 2009 09:57:30 -0400
Filipus Klutiero <chealer@gmail.com> wrote:
(Could you add a blank line between the quoted reply and your content?
It makes the content easier for me to read. Thanks.)
I'll try to.
> 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.
But the source package would still be the wrong source for the binaries
that exist. The archive needs to contain the unique source package for
the binaries that exist, modifying the source without modifying the
binaries is not an option for legal reasons, as I understand it.
I don't understand. If you have a source package which contains the
source for a set of binary packages A, and the source for a set of
binary packages B. You can change B's source without affecting A's
source. This allows an infinity of source packages for the same source
of A. Changing the source package does not imply a change in A's source.
> > 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).
Why treat the two differently?
I'm not sure I understand your question. In the case of a native
package, there is no diff, so you can't integrate the source changes for
translation debs there. In the case of a non-native package, orig is
upstream's business, so you can't integrate the source changes for
translation debs there. Unless you introduce a new file avoiding that,
you need to integrate changes to native packages in the source tarball,
and to integrate changes to non-native packages in the diff.
> > > > > > 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.
If the .dsc is modified, the source package no longer matches the
binaries that are in the archive that were built from the old .dsc.
Why?
Just who/what is supposed to modify the existing .dsc anyway? The
archive software?
That's indeed one way to do it.
[...]
The +t1.dsc is likely
to need to be signed but merging that with the existing .dsc could give
the utterly misleading impression that the nominated l10n person doing
the upload is somehow responsible for the binary packages that have
not been touched but are affected by the change to the .dsc.
I'm now aware that l10n NMUs caused such issues. It's possible they do,
but that impression would have a tiny impact.
Reply to: