Re: [RFC] can we just extend openembedded to get Isar 2.0

[Claudius Heine <claudius.heine.ext@siemens.com>]

Hi,

On 07/25/2017 08:08 AM, [ext] Jan Kiszka wrote:
> On 2017-07-25 00:53, Baurzhan Ismagulov wrote:
>> On Fri, Jul 21, 2017 at 09:31:05AM +0200, Jan Kiszka wrote:
>>>>>> Claudius already suggested building custom .debs in Isar to solve that.
>>>>
>>>> Yes. we built them where the effort was justified.
>>>
>>> No, this is about making this feature available as library (class) so
>>> that you write three lines of recipe and have a customization deb
>>> package. That effort would be minimal for the user, and we only need to
>>> solve this once properly. If OE-core cannot provide that, we will have
>>> to implement it ourselves.
>>
>> Ah, I see. This is also on TODO. This is an example what we could do for Debian
>> people, and this is what other tools don't provide.
>>
> 
> OK, great. Then the question is likely if we should extend or write a
> separate tool for that or rather a bitbake recipe. Claudius was in favor
> of a recipe, Henning found some tool in Debian.

I am more in favor of a bbclass for this. Creating simple packages this 
way should be easy compared to expressing runtime and build dependencies 
to upstream packages or own packages created by a bitbake recipe and 
resolving and installing them into the build chroot beforehand.
It would be great to get PACKAGES, RDEPENDS_${PN}, FILES_${PN}, etc. 
working again.

I am not sure of the best way to do these kind of tasks in isar.

To integrate isar into OE one way could be to have a recipe that fetches 
the packet index from the repository and populates the bitbake datastore 
with recipes or packages for every package in the repository at runtime. 
Or, if that is too hacky or does not scale well, hook into the 'DEPENDS' 
resolve mechansim and look into the debian package index there and 
generate recipes/packages into the datastore just for the requested 
packages.
Also integrate use qemu + native debian toolchain as alternative cross 
compiler. This might need some additional finagling.

>>>> You can copy the recipe from Isar, and OE will be able to multistrap. The
>>>> problem is, you can't do anything useful with that afterwards due to the
>>>> different base system and compiler. OE != Debian, just like Ubuntu != Debian.
>>>
>>> OK, that is a more concrete example to discuss: assumption of OE-core
>>> about the compiler and the build environment (when we are building, the
>>> exceptional case).
>>
>> Building is not an exceptional case, every product has its custom applications.
>>
> 
> Compared to the primarily goal, installing tons of prebuilt packages,
> it's exceptional to Isar. That's what I meant. I agree that we do need
> to build a handful of packages in most projects as well.

Maybe I am captain obvious here, but should be possible to build static 
binaries with muslc in oe. Those would be independent of the toolchain.

>> But while you are talking about percentage: What tools does OE provide? I'm
>> aware of isar-init-build-env, bitbake, wic, and runqemu. What else is there?
>>
> 
> Classes, the secret source to glue all that together and make it
> conveniently usable.
> 
>>
>> To summarize, what I hear:
>>
>> + Less effort to adjust tools for Debian in OE.

Some of them might be a bit too hopeful and based on my implementation 
proposal:

+ Less intrusive change to the build system (bitbake + oe)
   -> Less work to keep it working with upstream
   -> Higher chance of beeing integrated into upstream
   -> Resolve many regressions of isar (compared to bitbake + oe)
   -> No need to reimplement most of the functionality (creating 
packages, images)
   -> Mostly compatible with oe recipes

Cheers,
Claudius