Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/4] dhrystone: add a hash file
Date: Thu, 3 Dec 2015 11:44:24 +0100	[thread overview]
Message-ID: <20151203114424.6f129af3@free-electrons.com> (raw)
In-Reply-To: <56601AD5.1090608@imgtec.com>

Vicente,

On Thu, 3 Dec 2015 10:35:01 +0000, Vicente Olivert Riera wrote:

> >  > diff --git a/package/dhrystone/dhrystone.hash b/package/dhrystone/dhrystone.hash
> >  > new file mode 100644
> >  > index 0000000..9ea22a3
> >  > --- /dev/null
> >  > +++ b/package/dhrystone/dhrystone.hash
> >  > @@ -0,0 +1,2 @@
> >  > +# Locally calculated
> >  > +sha256 038a7e9169787125c3451a6c941f3aca5db2d2f3863871afcdce154ef17f4e3e  dhry-c
> > 
> > Hmm, what are we going to do if this file ever changes?
> 
> isn't the purpose of the hash files to ensure that we download exactly
> what we want to download, so we can make the builds reproducible?
> 
> If that file changes, we will notice it thanks to its hash file. You
> could ask the same for tarballs. What are we going to do if this
> tarballs ever changes?

It also took me a bit to understand Peter's comment. I believe what
Peter means is that this file has no version in its name. So if
upstream changes the file, the hash will change, and we will notice.
But it will break every previous Buildroot version that has been
released, since the old file can no longer be fetched from anywhere.

But unless I'm missing something, I believe that this is exactly what
we want: if upstream changes the file, it *does* affect old Buildroot
versions, and we want users of such old Buildroot versions to be loudly
notified that the dhry-c file they are building from is no longer the
same than the one that existed at the time the Buildroot they are using
was released.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  reply	other threads:[~2015-12-03 10:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-02 12:29 [Buildroot] [PATCH 1/4] dhrystone: add a hash file Vicente Olivert Riera
2015-12-02 12:29 ` [Buildroot] [PATCH 2/4] libglu: " Vicente Olivert Riera
2015-12-17 16:21   ` Thomas Petazzoni
2015-12-02 12:29 ` [Buildroot] [PATCH 3/4] torsmo: " Vicente Olivert Riera
2015-12-17 16:23   ` Thomas Petazzoni
2015-12-17 21:34     ` Peter Korsgaard
2015-12-02 12:29 ` [Buildroot] [PATCH 4/4] whetstone: " Vicente Olivert Riera
2015-12-17 16:23   ` Thomas Petazzoni
2015-12-02 20:45 ` [Buildroot] [PATCH 1/4] dhrystone: " Peter Korsgaard
2015-12-02 21:58   ` Arnout Vandecappelle
2015-12-02 22:03   ` Yann E. MORIN
2015-12-03 10:35   ` Vicente Olivert Riera
2015-12-03 10:44     ` Thomas Petazzoni [this message]
2015-12-03 11:42       ` Peter Korsgaard
2015-12-03 20:52         ` Peter Seiderer
2015-12-03 21:18           ` Peter Korsgaard
2015-12-17 16:20 ` Thomas Petazzoni

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=20151203114424.6f129af3@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox