source-only builds and .buildinfo

[Ian Jackson]

Daniel Kahn Gillmor writes ("Re: source-only builds and .buildinfo"):
> On Wed 2017-06-21 13:38:42 +0100, Ian Jackson wrote:
> > Certainly `dgit push' will not do anything to any .buildinfo you may
> > have.  I think maybe that your use case should be supported by having
> > a version of dgit push which drops the .debs from the .changes, but
> > leaves the .buildinfo ?  Is that how you construct these uploads now ?
> 
> I really don't have to do anything manually.  The standard
> dpkg-buildpackage toolchain does it for me if i pass
> --changes-option=-S  -- it all works as i expect, and kudos to the dpkg
> developers for that :)

Then I think `dgit ... sbuild ...' (a binaryful build) followed by
`dgit --ch:-S push' (a binaryless upload) will probably do the same
thing.

Definitely in this case, dgit ought not to mess with the .buildinfo.
(Ie I think it will be included in the .changes, and dgit ought to
leave it there.)

>  c) given this explicit set of build dependencies, here are the digests
>     of the binary packages that were produced on my system.
> 
> You say "verify my assertions about the .debs", i think you're talking
> about part (c), but there's nothing specifically to verify there.  I'm
> saying to the world what *i* found when i built them.  You want to tell
> me you found something different?  fine!  Now we have something to
> investigate.  You found the same thing?  Great, but that's a
> corroboration, not a verification.

Well, (c) is only useful if the build "is" reproducible.  (That is,
"is reproducible in some plausible scenario".)

> But i don't think that we need to officially "close the loop" in any
> fancy (or strict) way to warrant shipping .buildinfo files from
> developers.  The fancy console i propose above (or anything like it) can
> only be built and used across the archive once we have shipped the
> .buildinfo files.  Unnecessarily stripping .buildinfo files that we know
> about only delays that process.

My comments here are more of an aside.  I'm certainly not suggesting
that theis line of reasoning suggests any .buildinfos should be
stripped; merely that if I were you I would want to see about closing
this loop so because right now you are perhaps generating .buildinfos
which are going to be difficult to use this way in the future.

If some routine consumer of these .buildinfos comes into being, then
it would definitely be a good idea for dgit to gain convenient and
meaningful option(s) to generate such uploads.  More convenient than
`--ch:-S' (which is using an escape hatch, and hence undesirable for
routine use).


However, `dgit push-source' is a different case.  That is a command
where the dgit user asks dgit to upload their package source code to
Debian, but without doing any kind of binary package build at all.

(Probably the user has done some kind of pre-upload test to check that
the source does generate working binaries, but perhaps of a source
package with a different version in the changelog, or something.)

In that case, dpkg-buildpackage currently does still generate a
.buildinfo.  That .buildinfo does not contain any information about
binary package builds - since there were no binary package builds.

Nor is the build-dependency information in the .buildinfo particularly
useful even for figuring out in what circumstances the uploader was
able to successfully run `debian/rules clean'.  The experienced [d]git
user will probably be cleaning their working trees with git clean, not
rules clean.  And, regardless, even if the uploader did run rules
clean, this has no bearing on the source package that gets uploaded,
since dgit verifies that the source package is identical to the
uploader's git tree.


Part of the confusion in this thread is, I think, due to the
overloading of the term "source-only upload" for your hybrid upload
which did _build_ binaries, and describes them in the .buildinfo, but
does not actually _ship_ them.

This is a very useful concept but I suggest you give it a new name.
"binaries-attested upload" perhaps ?

To me "source-only upload" means that there were no binaries built,
and therefore no information about binaries included in the upload.


Regards,
Ian.