From: Martin Jansa <martin.jansa@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC] [PATCH] utils.bbclass: simplify checksum check, prepare for checksums.ini removal
Date: Thu, 8 Apr 2010 19:06:17 +0200 [thread overview]
Message-ID: <20100408170617.GF3269@jama> (raw)
In-Reply-To: <u2mb6ebd0a51004080941u2b296467h23c7e017a88b8d08@mail.gmail.com>
On Thu, Apr 08, 2010 at 09:41:37AM -0700, Chris Larson wrote:
> On Thu, Apr 8, 2010 at 6:40 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> >
> > * unify OE_STRICT_CHECKSUMS and OE_ALLOW_INSECURE_DOWNLOADS, one option
> > for insane people should be enough, when the later is enabled, don't
> > raise Exception even for missing md5sum/oe_sha256sum command or
> > different checksums
> >
>
> I find it very useful to distinguish between the missing checksum and
> invalid checksum cases. The latter should really never be allowed, at all,
> period, imo, but the missing checksum should have an option. If we aren't
> ready to remove the ability to allow invalid, then we need to be able to
> control the two cases independently, or via two different values in the
> variable that controls the behavior.
OK fair enough, I've expected this.. (that's also why it's RFC :)). Do
you agree that with enabled OE_ALLOW_INSECURE_DOWNLOADS it should
continue even when it's not possible to check checksum (like missing
md5sum/oe_sha256sum command)?.
> * show note, when there are checksums only in checksums.ini (prepare for
> > script for moving all to recipes)
> >
>
> This sounds good, though it may be something best relegated to an explicit
> sanity check, depending on how much it clutters the output. May want to log
> it to a file like tmp/legacy-staging.log, also.
>
>
> > * parse checksums.ini only when there is no checksum in recipe (could be
> > faster, but for more checked items in SRC_URI it is parsed repeatedly)
> >
>
> "Could be" .. sounds like this isn't ready to go in yet, need to do
> profiling. Changing something because it "could" be good is best done in
> proof of concept code, not as a part of a single patch like this one.
Both those points are assuming I'll be allowed to push "recipes: move
checksums from checksums.ini to recipes", which is being prepared ATM
with -c fetchall on all recipes. After this patch both bb.note output
as well as parsing checksums.ini should be needed only in rare cases.
> > * if one checksum doesn't match then count and show both (md5 as well as
> > sha256) - usefull for copy&paste checksums for new recipe.
Thanks for comments,
--
uin:136542059 jid:Martin.Jansa@gmail.com
Jansa Martin sip:jamasip@voip.wengo.fr
JaMa
prev parent reply other threads:[~2010-04-08 17:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-08 13:40 [RFC] [PATCH] utils.bbclass: simplify checksum check, prepare for checksums.ini removal Martin Jansa
2010-04-08 16:41 ` Chris Larson
2010-04-08 17:06 ` Martin Jansa [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=20100408170617.GF3269@jama \
--to=martin.jansa@gmail.com \
--cc=openembedded-devel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox