Re: source-only builds and .buildinfo
Daniel Kahn Gillmor writes ("Re: source-only builds and .buildinfo"):
> On Tue 2017-06-20 18:10:49 +0100, Ian Jackson wrote:
> > A .buildinfo file is not useful for a source-only upload which is
> > veried to be identical to the intended source as present in the
> > uploader's version control (eg, by the use of dgit).
> > Therefore, dgit should not include .buildinfos in source-only uploads
> > it performs. If dgit sees that a lower-layer tool like
> > dpkg-buildpackage provided a .buildinfo for a source-only upload, dgit
> > should strip it out of .changes.
> I often do source-only uploads which include the .buildinfo.
> I do source-only uploads because i don't want the binaries built on my
> own personal infrastructure to reach the public. But i want to upload
> the .buildinfo because i want to provide a corroboration of what i
> *expect* the buildds to produce.
This is an interesting use case which dgit should support.
But I think this is not what dgit push-source should do. Sean's
proposed dgit push-source does not do any kind of binary package
build. I think this is correct. But this means there are no binaries
and nothing for the .buildinfo to talk about.
Do the "source-only uploads" that you are talking about mention the
hashes of these locally-built .debs in their .buildinfo, then ?
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 ?
(Also: is there anything right now that verifies your assertions about
the .debs? Not that the lack of such a thing would make the
.buildinfos useless, but my experience is that without closing that
loop it is likely that the arrangements for generating the .buildinfo
are wrong somehow in a way we haven't spotted.)
> why wouldn't dgit take the same approach? stripping the .buildinfo from
> the .changes seems like a wasted shot at a potential corroboration.
> or am i misunderstanding the question here?
I hope you're misunderstanding. I'm open to being convinced I'm
Ian Jackson <email@example.com> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.