From: "Gaël PORTAY" <gael.portay@savoirfairelinux.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] support/download: print dl hash if not provided
Date: Mon, 23 Oct 2017 08:47:18 -0400 [thread overview]
Message-ID: <20171023124718.zsdv7exoc3j2guim@archlinux> (raw)
In-Reply-To: <c473939d-e763-165f-5451-cd940f56fa38@mind.be>
Hi Arnout,
On Mon, Oct 23, 2017 at 11:10:32AM +0200, Arnout Vandecappelle wrote:
> Hi Ga?l,
>
> On 11-09-17 21:12, Ga?l PORTAY wrote:
> > Yann,
> >
> > On Sun, Sep 10, 2017 at 11:29:55AM +0200, Yann E. MORIN wrote:
> >> Ga?l, All,
> >>
> >> On 2017-07-19 23:18 -0400, Ga?l PORTAY spake thusly:
> >>> ...
> >>>
> >>> It also fixes check_one_hash description. check_one_hash() takes three
> >>> arguments:
> >>> - algo hash
> >>> - known hash
> >>> - file to hash
> >>>
> >>> Signed-off-by: Ga?l PORTAY <gael.portay@savoirfairelinux.com>
> >>
> >> NAK from me.
> >>
> >> The reason we do not want this is that we instead want the user to go
> >> fetch the hash(es) as provided by upstream, like in an announcement
> >> email, or in an on-the-side hash file.
> >>
> >> Having the download infra print the locally computed hash defeats the
> >> very purpose of hashes: check that we get what upstream provides.
> >>
> >> We only accept local calculations of hashes for the cases where upstream
> >> does not provide any (or too weak) hash.
> >>
> >
> > Okay.
>
> Thomas and I discussed this at the BR developer meeting, and we disagree with
> Yann that we should make life difficult for people bumping a package :-P. So we
> think this patch does have value. Would you be willing to respin it?
>
For sure. Let me do a rebase and I will respin it at the end of the day.
> However, the text you propose is not strong enough. How about:
>
> Please find a hash in the upstream announcement or website
> and add it to ${h_file}
> If upstream doesn't provide a hash and the source is trusted,
> consider adding these lines:
>
I agree.
> Also, the most annoying thing actually is that when the hash is wrong, the
> just-downloaded file will be removed again. It would be convenient to avoid
> removing it, similar to how it is done when the file exists already.
>
I was thinking the same thing when write this patch. Let me see. I think it is
just another case to add in the download script.
Regards,
Gael
prev parent reply other threads:[~2017-10-23 12:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-20 3:18 [Buildroot] [PATCH] support/download: print dl hash if not provided Gaël PORTAY
2017-09-10 9:29 ` Yann E. MORIN
2017-09-11 19:12 ` Gaël PORTAY
2017-10-23 9:10 ` Arnout Vandecappelle
2017-10-23 12:47 ` Gaël PORTAY [this message]
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=20171023124718.zsdv7exoc3j2guim@archlinux \
--to=gael.portay@savoirfairelinux.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