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

[Frans Meulenbroeks]

2009/11/11 Holger Hans Peter Freyther <holger+oe at freyther.de>:
> On Tuesday 10 November 2009 17:55:40 Phil Blundell wrote:
>> The current checksums.ini arrangement has a number of issues:
>>
>>  - single monolithic file is a rich source of merge conflicts
>>  - concrete URIs require many duplicate entries for different mirrors
>>  - can be annoying for folks using overlays and/or collections
>>  - storing the checksum separately from the rest of the .bb file makes
>> cherry-picking harder than it needs to be
>>  - large amount of churn in checksums.ini can make it hard to spot cases
>> where checksums were changed rather than just added.
>>
>> It was proposed that, rather than storing checksums centrally in
>> checksums.ini, they should be placed in the individual .bb file to which
>> the checksum relates.  Bitbake already has a certain level of support
>> for reading checksums from SRC_URI and it would seem natural to try to
>> make use of that.
>
> *sigh*
>
> SRC_URI = "http://example.org/${PN}-${PV}.tar,bz2"
>
> how do you want to handle these? What happens if you place a checksum in the
> inc file? Do you want to propose removing SRC_URI from .ini files and put them
> back to the .bb files?

While I think the monolithic checksums.ini file has its problems (I've
cursed more than once that someone changed the fiel just wwhen I had
changed it), I think Holger has a point with ${PN}-{$PV}
One now needs to explicitly add the checksum to the recipe.

Would it be better to have a separate checksums.ini file in the
directory with the packages (and I know that for some dirs like perl
this still can become substantial)..
With some machinery we could even generate the checksum automatically
if a new package or version is added (NOT if the checksum is alreayd
there and is changed).

How about that?

Frans.