2009/11/11 Holger Hans Peter Freyther <[email protected]>:
> 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.
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
