All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael 'Mickey' Lauer <mickey@vanille-media.de>
To: openembedded-devel@lists.openembedded.org
Subject: Re: OEDEM 2009 summary: Death to checksums.ini?
Date: Wed, 11 Nov 2009 12:12:34 +0100	[thread overview]
Message-ID: <1257937954.6879.2.camel@opal> (raw)
In-Reply-To: <1257931062.25369.292.camel@lenovo.internal.reciva.com>

Am Mittwoch, den 11.11.2009, 09:17 +0000 schrieb Phil Blundell:
> On Wed, 2009-11-11 at 09:44 +0100, Holger Hans Peter Freyther wrote:
> > This will create an even bigger mess. Sometimes you need to download two 
> > things, this means you will end up with A_MD5SUM, B_MD5SUM, A_SHASUM, 
> > B_SHASUM. The main problem with the above is that in contrast to a well defined 
> > checksums.ini file we will end up with n-variants of the above trick.
> 
> The number of recipes where multiple items need to be downloaded and
> checksummed is small: this is a tiny minority of the total.  So,
> although I agree that this case will become more ugly, I don't think
> this is going to be a common enough problem that it will represent a
> very big deal.
> 
> > I agree that conceptually the checksum belongs to the URI, but putting it into
> > the URI is just creating a horrible mess. It has issues with .inc files, adding 
> > a shasum will make the URI not fit in any terminal...
> > 
> > The best alternatives so far where:
> > 	- Place the checksums into the dir of the recipe
> > 	- Use a MD5SUM_${URL} = "", SHA256SUM_${URL} = "" syntax
> 
> I would be happy with the latter of those suggestions.  I don't think
> the former really addresses the problems with the current checksums.ini.

I agree here, the latter syntax seems well.

:M:





  parent reply	other threads:[~2009-11-11 11:13 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-10 16:55 OEDEM 2009 summary: Death to checksums.ini? Phil Blundell
2009-11-11  1:06 ` Holger Hans Peter Freyther
2009-11-11  5:46   ` Frans Meulenbroeks
2009-11-11  8:24   ` Phil Blundell
2009-11-11  8:44     ` Holger Hans Peter Freyther
2009-11-11  9:17       ` Phil Blundell
2009-11-11  9:27         ` Frans Meulenbroeks
2009-11-11  9:43         ` Holger Hans Peter Freyther
2009-11-11 13:31           ` Phil Blundell
2009-11-11 13:37             ` Holger Hans Peter Freyther
2009-11-11 13:50               ` Holger Hans Peter Freyther
2009-11-11 10:06         ` Andrea Adami
2009-11-12 17:41           ` Ricardo Salveti de Araujo
2009-11-11 11:12         ` Michael 'Mickey' Lauer [this message]
2009-11-11 17:48         ` Esben Haabendal
2009-11-11 14:17       ` Richard Purdie
2009-11-11 15:45         ` Phil Blundell
2009-11-11 16:01           ` Frans Meulenbroeks
2009-11-11 16:06             ` Phil Blundell
2009-11-11 17:37               ` Frans Meulenbroeks
2009-11-11 20:34                 ` Phil Blundell
2009-11-11 20:48                   ` Frans Meulenbroeks
2009-11-12 18:36                   ` Phil Blundell
2009-11-12 19:18                     ` Bernhard Reutner-Fischer
2009-11-12 19:31                       ` Phil Blundell
2009-11-13 17:47                     ` Phil Blundell
2009-11-14  8:00                       ` Holger Hans Peter Freyther

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=1257937954.6879.2.camel@opal \
    --to=mickey@vanille-media.de \
    --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 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.