From: Peter Korsgaard <peter@korsgaard.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/4] dhrystone: add a hash file
Date: Thu, 03 Dec 2015 12:42:50 +0100 [thread overview]
Message-ID: <87610fep1h.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <20151203114424.6f129af3@free-electrons.com> (Thomas Petazzoni's message of "Thu, 3 Dec 2015 11:44:24 +0100")
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> > 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.
Yes, my reply was perhaps a bit too terse.
> But it will break every previous Buildroot version that has been
> released, since the old file can no longer be fetched from anywhere.
No, it will not break as long as we keep a backup of the old file on
sources.buildroot.net, as buildroot will fall back to using that.
> 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.
Agreed, but the problem is if upstream ever changes the file content (for
bugfixes or new features) then we cannot use the new version without
updating our sources.buildroot.net mirror (and hence break old
releases).
But ok, for something as old as dhrystone this probably isn't very
likely to happen (and we could carry the improvements/fixes as a local
patch if it does).
--
Venlig hilsen,
Peter Korsgaard
next prev parent reply other threads:[~2015-12-03 11:42 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
2015-12-03 11:42 ` Peter Korsgaard [this message]
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=87610fep1h.fsf@dell.be.48ers.dk \
--to=peter@korsgaard.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