Re: [bitbake-devel] [oe-core][PATCH 1/2] devtools: Initial recipe for repo 2.17.3

[Jasper Orschulko <jasper@fancydomain.eu>]

[-- Attachment #1: Type: text/plain, Size: 2749 bytes --]

Hi Alex,

> that you invented a custom, proprietary 
> workflow that you have to support entirely by > yourselves

We are not though. We are integrating an established tool for multi-repository management into yocto. Google repo is not proprietary by the way, it is permissive licensed. It is just a little "special" in it's modus operandi.

> instead of finding ways to do what you need
> with standard yocto tooling, improving the
> tooling where/if necessary.

But that is exactly what we are doing, by integrating the repo fetcher into the yocto workflow, thus improving the yocto tooling :)
Why reinvent the wheel, when you can reuse whats already there? You wouldn't reinvent git just for yocto, would you?

Best regards,
Jasper


On 5 November 2021 18:46:27 CET, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>On Fri, 5 Nov 2021 at 16:24, Jasper Orschulko <
>Jasper.Orschulko@iris-sensing.com> wrote:
>
>>
>> In our case some binary which is made up from some 50ish separately
>> versioned sub-components. We used to have separate recipes for each of
>> this components and static link them using DEPENDS. However, this does
>> not scale well. E.g. if you want to create another version with
>> different cmake flags, you would have to create copies of all 50ish
>> recipes. You could move all the components into a single recipe and do
>> 50x git fetcher, but keeping this versioned is still painful.
>> Especially since the developers mainly don't use yocto but use the SDK
>> for cross-compiling. As such this used to mean, that versioning in the
>> development workflow and the release workflow worked differently ->
>> more maintenance work.
>>
>> With repo fetcher we can streamline the versioning within the yocto
>> build process and the daily developer workflow, as both can fetch the
>> repo manifest from a central stored git repo. The idea is, that the
>> repo manifest defaults to develop branch for all component repos and if
>> we want to create a release we can use repos own tooling to
>> automatically create fixed refspecs from the development manifest.
>> something like `repo manifest -r -o release-1.0.0.xml`, push that as a
>> release to the manifest repo, set this release as refspec in the recipe
>> within the meta layer and proceed with the release process. So no more
>> manually maintaining the component versioning within the yocto recipes.
>>
>
>I see. I don't particularly endorse that you invented a custom, proprietary
>workflow that you have to support entirely by yourselves - instead of
>finding ways to do what you need with standard yocto tooling, improving the
>tooling where/if necessary. But if that works out ok for you, then fine :)
>
>Alex

[-- Attachment #2: Type: text/html, Size: 3394 bytes --]