kernel-yocto.bbclass ignoring SRCREV?

kernel-yocto.bbclass ignoring SRCREV?

[Wolfgang Denk]

Hi,

is my understanding of kernel-yocto.bbclass correct that it
effectively completely ignores any specific git commit ID that was
gien in SRCREV, but instead always checks out and uses the HEAD of the
respective branch?

Or am I missing something here?  My expectation was that we specify a
git commit ID (as the only reliable, truly unique identifier for a
specific source code version) in SRCREV, but instead it appears that
this information is effectively being ignored?

I can understand that there are situations where automatically using
the top commit of a branch (say, the latest stable version of some
package) may be useful, but should there not be some different way to
do that?

I mean, how can we make sure to ever be able to reproduce the very
same build if the git commit ID specified in SRCREV will not be used
for the checkout?

Thanks in advance.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"More software projects have gone awry for lack of calendar time than
for all other causes combined."
                         - Fred Brooks, Jr., _The Mythical Man Month_

Re: kernel-yocto.bbclass ignoring SRCREV?

[Bruce Ashfield]

On 14-05-21 08:33 AM, Wolfgang Denk wrote:
> Hi,
>
> is my understanding of kernel-yocto.bbclass correct that it
> effectively completely ignores any specific git commit ID that was
> gien in SRCREV, but instead always checks out and uses the HEAD of the
> respective branch?
>
> Or am I missing something here?  My expectation was that we specify a
> git commit ID (as the only reliable, truly unique identifier for a
> specific source code version) in SRCREV, but instead it appears that
> this information is effectively being ignored?

kernel-yocto does respect SRCREV. It uses the routine do_validate_branches
to reset to a specific SRCREV as a baseline, it then starts processing
and applying BSP descriptions on top of that point.

We test SRCREV specific builds on a ongoing basis, so they do work,
and if a different behaviour is being seen .. that's a bug.

Cheers,

Bruce

>
> I can understand that there are situations where automatically using
> the top commit of a branch (say, the latest stable version of some
> package) may be useful, but should there not be some different way to
> do that?
>
> I mean, how can we make sure to ever be able to reproduce the very
> same build if the git commit ID specified in SRCREV will not be used
> for the checkout?
>
> Thanks in advance.
>
> Best regards,
>
> Wolfgang Denk
>

Re: kernel-yocto.bbclass ignoring SRCREV?

[Bruce Ashfield]

On 14-05-21 08:44 AM, Bruce Ashfield wrote:
> On 14-05-21 08:33 AM, Wolfgang Denk wrote:
>> Hi,
>>
>> is my understanding of kernel-yocto.bbclass correct that it
>> effectively completely ignores any specific git commit ID that was
>> gien in SRCREV, but instead always checks out and uses the HEAD of the
>> respective branch?
>>
>> Or am I missing something here?  My expectation was that we specify a
>> git commit ID (as the only reliable, truly unique identifier for a
>> specific source code version) in SRCREV, but instead it appears that
>> this information is effectively being ignored?
>
> kernel-yocto does respect SRCREV. It uses the routine do_validate_branches
> to reset to a specific SRCREV as a baseline, it then starts processing
> and applying BSP descriptions on top of that point.

And I forgot to point out that do_validate_branches() has been nearly
completely removed/rewritten as part of the upcoming yocto 1.7
development cycle. So what I mention above is more clear in the new
versions.

Bruce

>
> We test SRCREV specific builds on a ongoing basis, so they do work,
> and if a different behaviour is being seen .. that's a bug.
>
> Cheers,
>
> Bruce
>
>>
>> I can understand that there are situations where automatically using
>> the top commit of a branch (say, the latest stable version of some
>> package) may be useful, but should there not be some different way to
>> do that?
>>
>> I mean, how can we make sure to ever be able to reproduce the very
>> same build if the git commit ID specified in SRCREV will not be used
>> for the checkout?
>>
>> Thanks in advance.
>>
>> Best regards,
>>
>> Wolfgang Denk
>>
>