[oe] OEDEM 2009 summary: Death to checksums.ini?

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Wed Nov 11 20:48:49 UTC 2009


2009/11/11 Phil Blundell <philb at gnu.org>:
> On Wed, 2009-11-11 at 18:37 +0100, Frans Meulenbroeks wrote:
>> 2009/11/11 Phil Blundell <pb at reciva.com>:
>> > On Wed, 2009-11-11 at 17:01 +0100, Frans Meulenbroeks wrote:
>> >> 2009/11/11 Phil Blundell <philb at gnu.org>:
>> >> > On Wed, 2009-11-11 at 14:17 +0000, Richard Purdie wrote:
>> >> >> SCR_URI = "xyz://abc.com/efg.tgz;name=bar"
>> >> >>
>> >> >> MD5SUM_bar = ""
>> >> >>
>> >> >> or maybe :
>> >> >>
>> >> >> MD5SUM[bar] = ""
>> >> >
>> >> > The labelling is a good idea, although I am not especially keen on
>> >> > either of those notations.  How about:
>> >> >
>> >> > SRC_URI = "xyz://abc.com/efg.tgz;name=bar"
>> >> > SRC_URI[md5sum:bar] = "..."
>> >> > SRC_URI[sha256sum:bar] = "..."
>> >> >
>> >> Would we still be able to use PN and PV in the md5sum:bar etc?
>> >
>> > Not directly, though it isn't entirely obvious to me why this would be a
>> > useful thing to do.  Did you have a situation in mind where this would
>> > be desirable?
>> >
>> I am somewhat lazy so if a new version of a recipe has to be made I'd
>> like to touch as little as possible.
>> (the less I have to do the less chance of an error occurring)
>> So preferably I would use PV an PN in the url and not copy it from
>> somewhere (as that is more error prone too.
>
> That should still work fine.  The purpose of the "name=bar" thing is to
> decouple the checksum from the exact URI in use.  So, you can write:
>
> SRC_URI = "${MIRROR}/somedir/${PN}-${PV}.tar.gz;name=mytarball \
>           ${OTHERMIRROR}/${PN}-${PV}-extra-files.tar.gz;name=extrafiles"
>
> and then, in another file if you prefer, add:
>
> SRC_URI[md5sum:mytarball] = "d3b07384d113edec49eaa6238ad5ff00"
> SRC_URI[md5sum:extrafiles] = "c157a79031e1c40f85931829bc5fc552"
>

Ah ok, now I understand. I thought at the place of bar I would get the
url, not a name tag associated to the url.

Thanks for clarifying , Frans




More information about the Openembedded-devel mailing list