IMHO, touching our copy of bitbake is an absolute NoGo! Such changesOn 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?
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
>