public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Claudius Heine <ch@denx.de>
To: Henning Schild <henning.schild@siemens.com>, isar-users@googlegroups.com
Subject: Re: [RFC] can we just extend openembedded to get Isar 2.0
Date: Thu, 20 Jul 2017 11:03:53 +0200	[thread overview]
Message-ID: <1500541433.16498.1.camel@denx.de> (raw)
In-Reply-To: <20170720103037.794aab2e@md1em3qc>

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

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-07-20  9:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-20  8:30 Henning Schild
2017-07-20  9:03 ` Claudius Heine [this message]
2017-07-20  9:15 ` Jan Kiszka
2017-07-20 23:05   ` Baurzhan Ismagulov
2017-07-21  7:31     ` Jan Kiszka
2017-07-24 22:53       ` Baurzhan Ismagulov
2017-07-25  6:08         ` Jan Kiszka
2017-07-25  8:06           ` Claudius Heine
2017-07-27 13:14             ` Kazuhiro Hayashi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1500541433.16498.1.camel@denx.de \
    --to=ch@denx.de \
    --cc=henning.schild@siemens.com \
    --cc=isar-users@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox