Including build metadata in packages

[Paul Wise]

Simon McVittie wrote:

> Relatedly, I would like to be able to capture some information about
> builds even if (perhaps especially if) the build fails.

That is a good point that I hadn't considered.

> so that failing builds can also produce artifacts, to help the
> maintainer and/or porters to figure out why the build failed.

Agreed that this is useful.

> handling build logs is not dak's job (and I don't think handling
> things like the binutils test results should be dak's job either).

It has always felt weird to me that build logs are entirely separate to
the archive off in a side service rather than first-class artefacts
that people occasionally need to look at. Also that the maintainer
build logs don't end up anywhere and are probably just deleted. I think
the same applies to the buildinfo files and also these tests results
and other artefacts that are mentioned in this thread.

> Here's a straw-man spec, which I have already prototyped in
> <https://salsa.debian.org/debian/sbuild/-/merge_requests/14>:

This seems better than my proposal, modulo the above and also the repro
builds need for a way to distribute buildinfo files somehow.

IIRC last time the build artefact discussion came up I was cycling
between having the artefact handling in the sbuild configs on the
buildds for quick implementation vs having it in debian/ dirs for
distributed maintenance by maintainers.

I think there is a fundamental question here that needs answering
definitively: who is the audience for the artefact feature?

 * Is it individual package maintainers who want test result details?
 * Is it build tool maintainers who want data on tool use/failures?
 * Is it porters who want more detailed logs in case of failure?
 * Is it buildd maintainers for some reason?
 * Is it RC bug fixers?
 * Is it all of the above?

Once that is answered, then we can think about how to accommodate how
and where the list(s?) of files are to be maintained?

 * in debian/
 * in build tools (meson, gcc etc)
 * in debhelper extensions
 * in debhelper
 * in wanna-build
 * in sbuild
 * in sbuild.conf in dsa-puppet
 * in sbuild overrides on buildds

Some of the above will be faster to implement and some will be slower.
The faster parts can possibly even make up for the slower parts, by for
example doing the sbuild proposal in hooks until it is done in stable.

Then there is the question of how the files get off the systems where
builds happen (buildds, maintainer systems). Again, the faster/slower
implementation implications exist here too.

Then there is the question of how the files are further distributed
from there and the question of how people access them.

Then there is the question of whether any of the above will be
implemented in a way that is useful solely to Debian, or in a more
general way to all Debian or apt repository based distributions. Being
able to publish build logs/artifacts seems like something other distros
would be interested in. It sounds like at least the GCC maintainers
want that for too Ubuntu at minimum.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20220216/9d55a3f9/attachment.sig>