Cross-check autobuilt binary pkg with maintainer-provided pkg
On Sun, 13 Feb 2011, brian m. carlson wrote:
> On Sun, Feb 13, 2011 at 06:00:11PM +0000, Lars Wirzenius wrote:
> > That's something I don't understand. If I upload a broken package, why
> > should it be the buildd admin's job to deal with it? Should not I get
> > notified of the error, and told to fix it?
>
> I've seen packages that don't fail until the very end of the build.
> This can waste a lot of buildd time, especially on very large packages.
> So yes, as the maintainer, it may be your problem to fix, but failing to
> test packages that as a result fail on the buildds won't make the buildd
> admins very happy.
This is a good reason to forbid source-only uploads, but there is another,
which actually leverages what we do now, and the idea of not using the
maintainer-provided binary packages in order to have better determinism on
the build:
1. Instead of discarding upon upload the maintainer-provided binary uploads,
we should first retain some interesting metadata[1] about it, and then
discard.
* Packages that outright FTBFS won't get uploaded
2. Autobuild all binary packages (determinism, clean chroot, etc)
3. Compare the metadata on the autobuilt binary packages and the binary
packages originally uploaded by the maintainer
4. Notify of any important discrepancies (through PTS, *automated*):
1. Changed dependencies
2. Changed file names (new/missing)
3. (large?) changes to file sizes
4. Changed linking information
...
This can help with the build-conflicts issues, plus raise an alarm for the
maintainer about his building environment _or_ about something weird going
on with the autobuilder.
We are not adding any extra pain for any maintainers, they upload exactly
what they are already uploading today. We are also not adding to the normal
operational workload of the autobuilder operators, as we are not increasing
the FTBFS probability, nor adding any non-automated steps.
[1] Where metadata means dumps of the information we might want in step (4),
but could also be the entire binary package. Whatever is more practical.
Obviously, it should be discarded after a small while (one week? one
month?).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: