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

Alexander Kanavin alex.kanavin at gmail.com
Thu Jan 9 11:26:39 UTC 2020


I think you can do this with a little help from devtool:

devtool upgrade component
devtool finish component layer-path
git add/commit layer-path
bitbake component

This has the added benefit of keeping things deterministic and reproducible.

You can further automate these steps with help from AUH:
https://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/about/

Alex

On Thu, 9 Jan 2020 at 11:52, Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:

> On Wed, 2020-01-08 at 13:10 +0100, Pascal Huerst wrote:
> > I'm looking for a way in yocto to build tagged releases or actually
> > to build the newest tagged release from repositories.
> >
> > There is a way to specify a branch or a tag in a recipe, but no way
> > to always clone the newest tagged release, that I'm aware of. I
> > submitted a patch to bitbake's mailing list with a proposal [1], that
> > would use bitbake's `latest_versionstring()`, to always find, fetch
> > and build the latest tagged release. Unfortunately there wasn't much
> > of a reaction on that proposal, so I'm taking a step back, collecting
> > ideas on how this could be achieved properly.
> >
> > Please share your ideas...
>
> 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)
>
> 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".
>
> 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...
>
> Cheers,
>
> Richard
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20200109/cd7d1ed2/attachment.html>


More information about the Openembedded-core mailing list