Hi,

On 10/19/2017 12:24 PM, Ben Brenson wrote:

2017-10-19 11:15 GMT+02:00 Henning Schild <henning.schild@siemens.com>:

On Thu, 19 Oct 2017 11:01:28 +0200
"[ext] Claudius Heine" <claudius.heine.ext@siemens.com> wrote:

Hi Ben,

On 10/19/2017 10:38 AM, 'Ben Brenson' via isar-users wrote:

Hi,

I want to submit some patches for defining and running chroot tasks
within bitbake recipes.
The following short example should show what I mean:

Exampe recipe.bb:

do_foo() {
      # Do something within chroot
}
do_foo[chroot] = "1"
do_foo[id] = "${BUILDCHROOT_ID}"
addtask do_foo after ... before ...


By setting the chroot flag the task automatically will be executed
within the chroot specified by the id flag.
My isar (https://github.com/benbrenson/isar) fork already supports
this feature, by using schroot.

This will give much more flexibility and modularity to Isar. You
will be able to append/prepend things to those tasks
between layers easily.

I have already seen, that there is another and better approach than
schroot -> proot.
I saw Alexander has already experimented with this feature, which
seems to work.

So before posting some patches here, maybe changing this feature to
proot first would a better first-step?

Yes. Since proot solves some more problems than schroot.

Your implementation requires patching the bitbake code, so maybe we
should try to get those changes upstream to bitbake?

IMHO, touching our copy of bitbake is an absolute NoGo! Such changes
need to go upstream first.

>>

Yeah I know, but using chroot tasks was never a use case for bitbake and
maybe will never be, I think.
I've never thought about using chroot tasks when running Yocto builds, but
that has changed very fast when switching to Isar.
So maybe within Isar we have a more reasoned use case for chroot tasks, and
if this feature works in isar, may be I have more chances to get those
changes upstream to bitbake?

I can try to get those changes upstream first....

A version that is independent of the chroot implementation might be more useful upstream maybe. Call it a 'execution context' then you can specify if a specific task should be run in a chroot environment, in a ssh shell. Some repl or a programming language or the serial tty session might a bit to much though but maybe possible.

Cheers,

Claudius

--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de