On Wed, 2023-09-06 at 23:27 +0200, Alexander Kanavin wrote: > On Wed, 6 Sept 2023 at 22:53, Richard Purdie > <richard.pur...@linuxfoundation.org> wrote: > > That test/calls were fairly recently added: > > > > https://git.yoctoproject.org/poky/commit/meta/lib/oeqa/selftest/cases/meta_ide.py?id=9b3fcb0d91648ae3b53ec8ffcb31fb6eac9209dd > > > > That test should probably call: > > > > bitbake("build-sysroots -c build_native_sysroot") > > bitbake("build-sysroots -c build_target_sysroot") > > > > om the setup case and then just call the target piece again in the > > specific test. > > > > We could drop the "before do_build" in the build-sysroots recipe. > > > > Note that the tasks are nostamp so they will always rerun. It does make > > sense to have a way to regenerate the target sysroot only but if you > > change it as you suggest, that becomes impossible. > > Setting up the 'direct esdk' would become somewhat more awkward as it > does currently rely on being able to run 'bitbake build-sysroots' > directly as officially published: > (yes the doc formatting needs to be fixed): > > https://docs.yoctoproject.org/sdk-manual/extensible.html#setting-up-the-extensible-sdk-environment-directly-in-a-yocto-build > https://docs.yoctoproject.org/sdk-manual/extensible.html#when-using-the-extensible-sdk-directly-in-a-yocto-build > > I can fix both the test and the documentation to run first native, > then target task explicitly, but I would really prefer to make > 'bitbake build-sysroots' just work without chance of failures.
Taking a step back, is user information actually useful in the context of these sysroots? Really, you shouldn't need the native sysroot for the target one. We only have postinsts for sysroots where they were absolutely unavoidable: * useradd * xmlcatalog * ldso/qemu issue * pixbuf Basically, they're on used for "index" creation issues. Ideally we'd not have these things at all, they're horrible to have to hack in. In the context of external SDKs, useradd doesn't make much sense. Even for "in-tree" use, given the significant dependency creep, I'm starting to think we should drop the useradd calls from the postinst script and code something else to create the right passwd/group entries which is all we care about (to keep pseudo working ok for packaging). The reason the dependency creep worries me is I know what the code internal to bitbake does when it hits these dependencies. It is really suboptimal :(. I know it is really tempting just to add dependencies and ignore the deeper issues but some of this really doesn't make sense when you step back and think about it. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187358): https://lists.openembedded.org/g/openembedded-core/message/187358 Mute This Topic: https://lists.openembedded.org/mt/101197363/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
