Moving towards a deb-buildinfo(5) Format 1.0
Johannes Schauer
josch at debian.org
Sun Nov 13 13:21:45 UTC 2016
Hi,
Quoting Chris Lamb (2016-11-13 12:25:07)
> > move the build date inside the .buildinfofile in a Build-Date field or
> > similar
> Hrm. Are we sure about this? My gut tells me that the external definition of
> the build should not include the Build-Date. (At the very least, this is just
> a duplication of SOURCE_DATE_EPOCH?)
the Build-Date is not SOURCE_DATE_EPOCH because the latter is deterministic
(obtained from the last Debian changelog entry). Multiple builds of the same
source package will set SOURCE_DATE_EPOCH to the same value but will result in
a different Build-Date.
The .buildinfo files are not supposed to document the minimum amount of
information that should be required to reproduce the build. Whether or not you
use the information included in the .buildinfo to reproduce the build is up to
you. For example the Build-Path is also still part of the .buildinfo even
though we currently demand builds to be independent of it. In the same vane,
you might later decide that the build should also be independent of the
Build-Architecture. As such, the .buildinfo file contains lots of happenstance
information.
Also see:
https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles#Semantics
I've heard many upstream developers who were initially very much against
purging the timestamp when the build was done from their build artifacts
because they valued the information of when a build was done (whatever their
reasons are). So this information could simply be retained in that field in the
.buildinfo file.
Thanks!
cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20161113/f884964b/attachment.sig>
More information about the Reproducible-builds
mailing list