<div dir="ltr"><div>I think you can do this with a little help from devtool:</div><div><br></div><div>devtool upgrade component</div><div>devtool finish component layer-path</div><div>git add/commit layer-path</div><div>bitbake component</div><div><br></div><div>This has the added benefit of keeping things deterministic and reproducible.</div><div><br></div><div>You can further automate these steps with help from AUH:</div><div><a href="https://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/about/">https://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/about/</a></div><div><br></div><div>Alex<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 9 Jan 2020 at 11:52, Richard Purdie <<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 2020-01-08 at 13:10 +0100, Pascal Huerst wrote:<br>
> I'm looking for a way in yocto to build tagged releases or actually<br>
> to build the newest tagged release from repositories.<br>
> <br>
> There is a way to specify a branch or a tag in a recipe, but no way<br>
> to always clone the newest tagged release, that I'm aware of. I<br>
> submitted a patch to bitbake's mailing list with a proposal [1], that<br>
> would use bitbake's `latest_versionstring()`, to always find, fetch<br>
> and build the latest tagged release. Unfortunately there wasn't much<br>
> of a reaction on that proposal, so I'm taking a step back, collecting<br>
> ideas on how this could be achieved properly.<br>
> <br>
> Please share your ideas...<br>
<br>
I did look at and think a bit about your patch. The trouble for me (as<br>
the bitbake maintainer) is that:<br>
<br>
a) it isn't clear/obvious from the variable name what it does (or even <br>
from the code)<br>
b) it adds yet more options to the fetcher which increases the test <br>
matrix and possible ways things can break<br>
c) the test doesn't actually test it does what its supposed to (no <br>
check is made on which output is downloaded for a given revision)<br>
<br>
Some of these can be fixed, some are much harder and I can't decide if<br>
supporting this kind of edge case is going to be an overall good thing<br>
for the project or not. I don't want to give you false hope by fixing<br>
c) only to say "no".<br>
<br>
Add in Khem's valid concerns about reproducibility and it makes it a<br>
tough one even to give feedback on.<br>
<br>
If we have a ton of users saying "yes we really need this", that would<br>
help but I haven't seen that as yet...<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
<br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div>