I will look into the more "direct" sdk - and I can see the idea to
limit the need for generating SDK artifacts.
Though I need to test how it handles breaking changes, and that you
can just "bitbake" the dummy app and it has the needed parts for
building the app itself.
Also if I am going that route at a certain point, it will require
significant infrastructure changes on my part - as we are using the
generated SDK all over in CI.
E.g. docker images with the SDK installed - and I can't see it is easy
to replicate this.
A side note - now that I looked into how this new change was done.
In reality the "NO_RECOMMENDATIONS" variable is now useless. No matter
what you set it to - the behaviour is that it is always set to 1.
<snip>
grep -R no-install-recommends *
meta/lib/oe/package_manager/deb/__init__.py: extra_args =
"--no-install-recommends"
meta/lib/oe/package_manager/ipk/__init__.py: cmd += "
--no-install-recommends"
meta/classes-global/package_deb.bbclass:APT_ARGS = "${@['',
'--no-install-recommends'][d.getVar("NO_RECOMMENDATIONS") == "1"]}"
meta/classes-global/package_ipk.bbclass:OPKG_ARGS += "${@['',
'--no-install-recommends'][d.getVar("NO_RECOMMENDATIONS") == "1"]}"
</snip>
I am puzzled that we did not just change the default of
NO_RECOMMENDATIONS to 1, and then kept the option for enabling
installing of soft dependencies, and adding a note that you are on
your own if you disable it.
Would it be better if a patch created a "new" variable with
INCLUDE_RECOMMENDATIONS - default to false, and with notice that
enabling it you are on your own.
What is the future plan for SDK - is it to only support the "direct" eSDK?
PS - It could also be a topic for Yocto Project Developer Day next
month (hope to meet many of you there)
On Mon, Aug 26, 2024 at 11:42 AM Alexander Kanavin
<[email protected]> wrote:
>
> On Mon, 26 Aug 2024 at 11:26, Claus Stovgaard <[email protected]>
> wrote:
> >
> > Will look more into it eSDK, though I would expect other also has the
> > need to generate SDK to support app teams without the specific app
> > itself part of the SDK, but with all the dependencies for the app.
>
> I was referring not to the classic 'esdk' (where you bundle a 'locked'
> yocto build into a tarball and distribute that), but rather the new
> 'direct' sdk, where you run a few bitbake commands to populate
> sysroots etc. (running them doesn't require 'knowing yocto'), and then
> compose a regular SDK environment from that. This cuts out the need to
> generate and distribute clunky SDK artifacts, but you do need well
> functioning sstate infra. Then making changes to 'yocto' (e.g. new
> boost) and fixing the apps becomes far simpler and more direct.
>
> Docker images tend to grow huge without upper bounds, as every team
> wants 'their stuff' in it, and you can never know if anything can be
> trimmed out until someone comes screaming at you for breaking 'their'
> team process.
>
> I wouldn't say it's right for app devs to not care (or want to know
> anything) about how their work is integrated into a complete system.
> Well rounded experts should know the product pipeline.
>
> If you want to stay with the current 'classic SDK tarball' approach,
> I'd tweak TOOLCHAIN_ variables, possibly with a script that looks at
> what apps produced by recipes actually use and need (so unnecessary
> items don't linger in that list forever).
>
> Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203745):
https://lists.openembedded.org/g/openembedded-core/message/203745
Mute This Topic: https://lists.openembedded.org/mt/108100662/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
