Re: Introducing chroot tasks

[Ben Brenson <benbrenson89@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 3718 bytes --]

In my opinion I think when introducing these feature, this may change
Isars' architecture and further development.
Maybe no scripts are copied into the chroot and executed inside it anymore.

Instead those taks (setupscript.sh, build.sh, setup.sh) will directly be
defined within the recipes.
That would gave us the possibility of reusing all parts of the core isar
layer and also overwrite them if needed.

I think, creating scripts copying them somewhere and then execute them, is
not for what bitbake was made for.
It's much more powerfull and we should make use of it.

So when it is possible to integrate this feature, we should think about of
integrating it know.

Maybe we can patch those 100 lines of code, a try to get it upstream
meanwhile.


Regards,
Benedikt



2017-10-19 14:00 GMT+02:00 Claudius Heine <claudius.heine.ext@siemens.com>:

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

[-- Attachment #2: Type: text/html, Size: 5509 bytes --]