source-only builds and .buildinfo

[Sean Whitton]

On Wed, May 24, 2017 at 11:59:55AM +0100, Ian Jackson wrote:
> > So I think for `dgit push-source', there should be no .buildinfo ?
> > At least, unless dgit ran the clean target.
> > 
> > This suggests to me that dgit push-source should use dpkg-source
> > rather than dpkg-buildpackage, as you note in later in the FAQ entry:
> > 
> >   If the intention is to just produce a source package instead of an
> >   actual build to upload, then using dpkg-source is always the better
> >   option.
> > 
> > This wording is a bit unclear.  It conflates `build' and `for upload'.
> > I think regarding `dgit push-source' as a build is perverse.
> > 
> > dgit would have to run dpkg-genchanges.
> > 
> > Alternatively dgit could strip out the .buildinfo, depending on
> > whether it ran rules clean.

While a plain `dgit push-source` will prepare a fresh .dsc and .changes,
we also want it to work with -C, which allows the user to supply an
existing .dsc and .changes.  So even if we use dpkg-source and
dpkg-genchanges directly, we still need a validation function that says
whether a .changes is source-only.

Alternatively we could have dgit not accept -C with push-source.  This
would be to think of push-source as a command to /do/ a source-only
upload, rather than a variant on `dgit push` that /ensures/ a
source-only upload.  This is probably fine.

-- 
Sean Whitton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20170524/3dc9a20f/attachment.sig>