On Thu, 2017-07-20 at 10:30 +0200, 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.

I agree. Currently looking at the debian package creation code in
openembedded and thinking about how to reimplement this rather complex
and featureful code into isar is what triggered this line of thought
for me.

There is a lot of stuff in bitbake that is written for openembedded in
mind, so retrofitting it to a completely different build process seems
like an anti-pattern to me. Going the other way and integrating the
debian repositories as a binary package source into openembedded seems
more reasonable, and might be doable with the same or less amount of
code.

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

            PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
                              Keyserver: hkp://pool.sks-keyservers.net