Re: Official policy to list checksums

[Koen Kooi <k.kooi@student.utwente.nl>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25-01-10 09:43, Denys Dmytriyenko wrote:
> On Mon, Jan 25, 2010 at 09:19:07AM +0100, Koen Kooi wrote:
>>>> * it has no tools to autogenerate it
>>>
>>> Give me few minutes - I'll send something to address this point.
> 
> Do you have any feedback on the patch I sent? Does it make things any better?

It seems to automate things a bit more, but I haven't tested them yet.

> 
>>>> * has not been agreed on in any way.
>>>
>>> Actually, specifying checksums in corresponding recipes was agreed on during 
>>> the OEDEM in November. Using additional variable flags in base.bbclass was 
>>> added by Phil, since bitbake cannot handle SHA256 sums in SRC_URI. Although, 
>>> Richard mentioned he'd like to get it implemented in bitbake at some point:
>>> http://thread.gmane.org/gmane.comp.sysutils.bitbake.devel/1089/focus=1115
>>
>> Ah yes, stuff agreed at OEDEM, I see. I also remember that nearly
>> everything that was 'agreed' there got dis-agreed on the mailinglist here.
>> And I also remember that I said that to be consistent sane-srcrevs
>> should cease to exist as well :)
> 
> This way we won't get anywhere... :) I thought (maybe I'm wrong) everybody 
> agrees at least with the fact that central checksums.ini is not the best 
> approach.

It's not the best approach in a perfect world, but with the current
state of OE it is the best (or least bad) of the options out there.

> Keeping checksums in the metadata inside SRC_URI seemed like a 
> viable solution.

Yes, but there wasn't any agreement on this. The only thing that came
out of this is that Phil coded some stuff and committed it.

What started all this was that some people found using checksums.ini too
hard. We can argue about that, but anyway. Now we seem to end up with a
system that's actually harder to use (at least without your patches)
*and* is lacking the most basic docs. It's not in the wiki nor in the
in-tree docs.

> Are there any fundamental flaws with this method, besides 
> lacking some tools?

Complete lack of docs, e.g. what does the 'name' do? And why are people
doing http://foo.com/bar.c;name=tarball?

In ti/staging I've been giving them all unique names. Do I need to do
that? I 'name' even needed? I don't know and I suspect everyone minus
Phil doesn't either.

> BTW, I agree with you on the sane-srcrevs topic, if it's any consolation... :)

Good :) I want to be able to 'move' recipes between overlays and having
the checksums in the recipe itself is a step in the right direction,
having SRCREVs in the recipes themselves would be even better.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLXWqLMkyGM64RGpERAlHHAJ0ZrH+Q7vBIrxmQNbN1CpdETpRIEgCdGFSM
HoAqu5kPJ+8AEhruFIEq9Jg=
=hF0z
-----END PGP SIGNATURE-----