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
Attachment:
signature.asc
Description: PGP signature