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

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2017-07-20 10:30, Henning Schild wrote:
> Hi,
> 
> looking at Isar it basically is a bitbake recipe to extract a bunch
> of .debs into a rootfs. It also has support for a few more things, like
> (cross-)compiling your own packages, basic configuration etc. Things
> like image creation with wic have been added as well.
> 
> But a lot of things are still missing. For true customization one would
> need a way to smuggle files into the rootfs, patch files in there,
> execute scripts in there. Ideally with collision protection and special
> protection for config-files etc. Claudius already suggested building
> custom .debs in Isar to solve that.
> 
> Another thing i already came across is Image conversion .raw
> -> .qcow2/.vdi/.vmdk all that is missing in Isar. Same was true for the
> wic support until recently.
> 
> People that are coming from Yocto and want to switch to Isar will never
> get their recipes to work, because all the utils-classes are missing in
> Isar and would need to be ported/pulled-in.
> 
> Isar needs sudo, and someone has to integrate libpseudo.
> 
> Isar still has several small issues with correct rebuilds after config
> changes etc.
> 
> OE solved all those problems already, but what it can not do is
> fetch .debs from a mirror and bundle them together with multistrap. OE
> most likely contains a lot of other usefull stuff that we might need
> eventually. But without a doubt it also contains tons of stuff that we
> do not need and that might confuse users if the have to look into it.
> 
> Does it really make sense for us to reinvent all those OE-features in
> Isar, or should we just got the other way around and put the Isar
> features into OE?
> 
> At a first glance it looks like you have to teach OE to get debian
> packages and create a rootfs from them. Tell it to not compile anything
> at first. Probably much like the do_rootfs from Isar. We might get away
> with a layer on top of OE and maybe a few patches to OE that can maybe
> be mainlined. Or maybe the whole thing could become mainline OE some
> day.
> 
> Has anyone considered or even tried that already? Going down that road
> sounds like solving a lot of the open points in Isar at once, by
> adding a few 100 LoC to OE. But i might be totally wrong here.
> I guess everyone working on Isar needs a good technical answer to
> why we seemingly start from scratch.
> 
> Henning
> 

This is a very important architectural question as we need to decide now
where to focus our resources on: porting/implementing missing features
or enabling OE.

Baurzhan, Alex, I suspect you have thought about this before and may
provide some insights on the traps and pitfalls of an OE-core-based path.

I also take the freedom to add Yoshi and Daniel to this discussion to
bring in their meta-debian experience. Possibly, you solved some of the
issues regarding Debian with OE already, although you focus on
out-of-source building. Maybe this path would also allows us to move
even closer together. But that's still a 10000-meters view on the topic.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux