From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Alexander Kanavin <alexander.kanavin@linux.intel.com>,
Juro Bystricky <juro.bystricky@intel.com>,
openembedded-core@lists.openembedded.org
Cc: jurobystricky@hotmail.com
Subject: Re: [PATCH 1/1] rpm_4.14.0: clamp timestamps by default
Date: Wed, 03 Jan 2018 10:40:25 +0000 [thread overview]
Message-ID: <1514976025.5525.111.camel@linuxfoundation.org> (raw)
In-Reply-To: <fc0ebed5-abd0-9926-3c57-6443d7f22241@linux.intel.com>
On Wed, 2018-01-03 at 10:47 +0200, Alexander Kanavin wrote:
> On 01/03/2018 01:16 AM, Juro Bystricky wrote:
> >
> > Improve reproducibility by making sure that timestamps
> > in built rpms are not later than the value of SOURCE_DATE_EPOCH as
> > found in the environment.
> > Timestamps as usual when SOURCE_DATE_EPOCH is not set.
> I'm not sure I understand the necessity of this. What matters for
> reproducibility is that rpms install the same files; why is it
> important that the rpm file itself has exactly same build time and is
> otherwise identical bit by bit?
People have different definitions of reproducibility. For some its the
end binaries on the target system, for others its identical rpms.
Its certainly true that producing binaries that are more similar does
help us in a number of ways (e.g. churn in package feeds) so if we can
improve that without causing serious complexity issues, I'm broadly in
favour of it.
Cheers,
Richard
next prev parent reply other threads:[~2018-01-03 10:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-02 23:16 [PATCH 0/1] rpm_4.14.0: clamp timestamps Juro Bystricky
2018-01-02 23:16 ` [PATCH 1/1] rpm_4.14.0: clamp timestamps by default Juro Bystricky
2018-01-03 8:47 ` Alexander Kanavin
2018-01-03 10:40 ` Richard Purdie [this message]
2018-01-03 16:59 ` Bystricky, Juro
2018-01-04 12:16 ` Alexander Kanavin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1514976025.5525.111.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=alexander.kanavin@linux.intel.com \
--cc=juro.bystricky@intel.com \
--cc=jurobystricky@hotmail.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.