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....

Regards,
Benedikt





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.
>
> Henning
>
> > Isar has currently has no own changes to upstream bitbake and I am
> > not in favor of forking bitbake.
> >
> > Claudius
> >
>
>