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

Esben Haabendal esbenhaabendal at gmail.com
Wed Nov 11 17:48:28 UTC 2009


On Wed, Nov 11, 2009 at 10:17 AM, Phil Blundell <philb at gnu.org> wrote:
> 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.

That seems to depend on how must weigth you put on clean vs. "messy"
solutions.

>> 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.

Which part of the current checksums.ini problems does the former not resolve?

Isn't the main issue with checksums.ini is the merge nightmare it poses?
I don't see how this will be a big problem with per recipe checksums
files.

A per recipe checksums file is also the one solution I have seen
that would reduce manual work needed for OE developers to
actually maintain checksums.  And face it, we are for the most part lazy :-D

As I also made clear on OEDEM, I think it is important to make things
simpler and easier to work with.  Not cause more mess and come
up with additional hurdless for OE developers.

/Esben




More information about the Openembedded-devel mailing list