[OE-core] Looking for a way to build latest tagged releases in recipes

Pascal Huerst pascal.huerst at gmail.com
Thu Jan 9 13:36:13 UTC 2020



On 09/01/2020 13:08, Richard Purdie wrote:
> On Thu, 2020-01-09 at 12:59 +0100, Pascal Huerst wrote:
>> On 09/01/2020 11:51, Richard Purdie wrote> I did look at and think a bit
>> about your patch. The trouble for me (as
>>> the bitbake maintainer) is that:
>>>
>>> a) it isn't clear/obvious from the variable name what it does (or even 
>>>    from the code)
>>> b) it adds yet more options to the fetcher which increases the test 
>>>    matrix and possible ways things can break
>>> c) the test doesn't actually test it does what its supposed to (no 
>>>    check is made on which output is downloaded for a given revision)
>>
>> I certainly wouldn't insist on the name and considered it a proposal,
>> but you're right, it's not obvious at all. As for test-ability, I can
>> relate to your concerns and understand that you don't want to maintain a
>> corner-case like this - Which leads me to the conclusion that we should
>> probably rethink our internal concept for release builds...
>>
>>> Some of these can be fixed, some are much harder and I can't decide if
>>> supporting this kind of edge case is going to be an overall good thing
>>> for the project or not. I don't want to give you false hope by fixing
>>> c) only to say "no".
>>
>> Understandable.
>>
>>> Add in Khem's valid concerns about reproducibility and it makes it a
>>> tough one even to give feedback on.
>>>
>>> If we have a ton of users saying "yes we really need this", that would
>>> help but I haven't seen that as yet...
>>
>> Fair enough.
>>
>> Thanks for your thoughts!
> 
> FWIW I do want to see the system used to do things like this. I've kind
> of envisaged you'd do it "up front" though. For example it should be
> trivial for a script to use tinfoil, iterate through and generate an
> include file of the revisions you want, using the fetcher calls.

Sure. Writing some scripts to do the job was my first intend, but then I
was aiming for something that could potentially be merged upstream. But
I guess I underestimated the overall implications...

> Yes, its slightly more annoying to generate the config, then build it
> but if it stops the core becoming unmaintainable with corner cases,
> that could be the right decision.
> 
> If you do something like that it would be great to share it so others
> can see what you did and be able to build off it...

Sure. Will do.


More information about the Openembedded-core mailing list