On Wed 2017-06-21 13:38:42 +0100, Ian Jackson wrote: > This is an interesting use case which dgit should support.
cool!
> 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.
I don't know anything about "dgit push-source", so i defer to you on that.
> Do the "source-only uploads" that you are talking about mention the
> hashes of these locally-built .debs in their .buildinfo, then ?
yes. when building foo version 1.2-3, the .changes file mentions only:
- foo_1.2-3.dsc
- foo_1.2.orig.tar.bz2
- foo_1.2-3.debian.tar.bz2
- foo_1.2-3_amd64.buildinfo
and the buildinfo file mentions:
- foo_1.2-3.dsc
- libfoo_1.2-3.deb
- foo-tools_1.2-3.deb
I *do not* upload any of the *.deb files to the archive.
> 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 :)
> (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.)
In a standard upload of the type i'm describing i've asserted:
a) I built version 1.2-3 on amd64, and it should be included in debian
b) here are the digests of the source code (including debian packaging)
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.
I agree with you that it'd be nice in the future to "close the loop" by
having infrastructure that monitors all of these developer-generated
.buildinfo files, compares them to the buildd-generated .buildinfo
files, and provides some sort of interface for easy reasoning about
them. and such infrastructure could well show that something is wrong
with how we're generating .buildinfo files; that's fine, we'd then
modify how we generate buildinfo files going forward to correct it, if
necessary.
Imagine a fancy console that a debian developer could pull up which
shows a list of binary packages they submitted which differ from the one
being shipped by the archive, and which build-dependencies it noticed
were different (or, just shows a green light if it's the case all of
their current uploads have been corroboratively rebuilt). cool, eh?
Or some future, stricter debian variant might even want to only allow a
package to enter the archive if the binary packages created by the
buildd of the submitted architecture match the binaries claimed by the
submitting developer (i'm *not* proposing this for debian today. it
could introduce hassle and delay because of the concerns about build-dep
synchronization that Adrian raises, and we don't have the workflow for
it smooth enough yet).
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.
Regards,
--dkg
signature.asc
Description: PGP signature
