From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6444767352800149504 X-Received: by 10.28.91.211 with SMTP id p202mr202752wmb.8.1500541445146; Thu, 20 Jul 2017 02:04:05 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.24.197 with SMTP id 188ls150727wmy.10.gmail; Thu, 20 Jul 2017 02:04:04 -0700 (PDT) X-Received: by 10.28.129.212 with SMTP id c203mr216308wmd.31.1500541444638; Thu, 20 Jul 2017 02:04:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1500541444; cv=none; d=google.com; s=arc-20160816; b=vRHsO51f5KCsQrL6ER5RZbEiZGK5+IAH+KBMZAUgpygYImTow1pEwmT6ONHiFwzoQX 5MHh0ZtiHstj9G27xHTHf+FW8HXTgA07aHJBvpk+O3PkzN6F1aNOabs2iGhgJFcCxzRI kYb6MwPOHvl6c+N8/wKLBELesOTXa1UcmUviwU1XCkTiKHSD5HDIefdXbrm1n+j7+etz 6TT/NtGU5mARGaAQYfU3gMhUPFX571F4cwX6H7/vUjUrL7ji8Zh03EoV0HHUUxA5ullN DBzPkLIlgaLElmrlh96F06Q/aFjuJikPujn9y3KMB6wblXYFzj6nCKajPfRB6QB4nffE Yg5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:references:in-reply-to:date:to:from:subject:message-id :arc-authentication-results; bh=OL1Ntbnk++Aph21Hv6VOFDdZUwPFiQVXbFynh13MGJI=; b=Oq6iqkhZmBxYXhd+F/xxzAe1x50wNoH1SdYMrN6fUlcSzXGbJqnBmldcAOi5Ezhnh2 USfSvRqHFIt22GLoZHiidrze5UrS3ijl5GwPII3J6gZqMv4YggSb0KLJYf+fY20qIRNp 6OJwNgtpPMS4T6NPo0a9P8glrXKIClhsVCR37KWezs927OFoYGf2e3Fvh9VjInloeHad MT5BQbQYQGZVnH6LKCRQGuJH78kgKj+EcOnXudZiG9JoYJqe32uGdF0TR2UC3aTdTp0v IUiqbyMc2JfIdW9Uc9t7UVOyi76x0pzGFOreGfdhaYq6aIUPINZWlp3Q7oFIyz2waLsz NVWQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of ch@denx.de) smtp.mailfrom=ch@denx.de Return-Path: Received: from mail-out.m-online.net (mail-out.m-online.net. [212.18.0.9]) by gmr-mx.google.com with ESMTPS id 139si625846wmt.0.2017.07.20.02.04.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 02:04:04 -0700 (PDT) Received-SPF: neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of ch@denx.de) client-ip=212.18.0.9; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of ch@denx.de) smtp.mailfrom=ch@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3xCnyD2xwqz1qsDC; Thu, 20 Jul 2017 11:04:04 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 3xCnyD1CZVz3jgYy; Thu, 20 Jul 2017 11:04:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id Xx7HEnH7RhIR; Thu, 20 Jul 2017 11:03:59 +0200 (CEST) X-Auth-Info: 7MZCUc/4j/gpjWIc4Sghb6FtDFNN9QMLrcN5+vCGYJM= Received: from Speedport_W723_V_Typ_A_1_01_009 (p578a821c.dip0.t-ipconnect.de [87.138.130.28]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Thu, 20 Jul 2017 11:03:59 +0200 (CEST) Message-ID: <1500541433.16498.1.camel@denx.de> Subject: Re: [RFC] can we just extend openembedded to get Isar 2.0 From: Claudius Heine To: Henning Schild , isar-users@googlegroups.com Date: Thu, 20 Jul 2017 11:03:53 +0200 In-Reply-To: <20170720103037.794aab2e@md1em3qc> References: <20170720103037.794aab2e@md1em3qc> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-U7G+gF/AkXqWzvHrVjHi" X-Mailer: Evolution 3.24.4 Mime-Version: 1.0 X-TUID: hZBkJhpklcLA --=-U7G+gF/AkXqWzvHrVjHi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2017-07-20 at 10:30 +0200, Henning Schild wrote: > Hi, >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Isar needs sudo, and someone has to integrate libpseudo. >=20 > Isar still has several small issues with correct rebuilds after > config > changes etc. >=20 > 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. >=20 > 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? >=20 > 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. >=20 > 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 --=20 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 --=-U7G+gF/AkXqWzvHrVjHi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEb/LlnwDGvCgx2GTBEXPLGZgIsVMFAllwcfkACgkQEXPLGZgI sVN99Q/+K38Bv9WAObUb7Mso1qzGSnzG4dKBvMcIHs0tcsZrbtSalRvtbU4eAo/P FRsU6FpXPgrUeKZen+3Rr7T2J5Ql3zooyZHQYM4eHK9QAxLr1NpAgYDgHb6TFXXj c4RcG1q49H7aznOTDvTKPMEM/HeJ51qsxDRAd+szEhKDleA9NowMbWr4WLI6HzQB suSHHjSJbfA31mUxltNCznbJJHSnRbDNhP+t8HnYOsauAEXS2sTgpegNLx/8kD4Y VhY72RYaPdBCc7oNFRS3fKRZuhufAVpU5+f/FuO9Y9Tcghfd7D0Cf3j/STr9tOIz RLZaQAsmXB3gdyBpE+FVcy+3M52BHPo5KTamvz19I/y6WlVSiXe+2SO0On59Ev8C q16CHXAB4jdxIOoDw669WQGuv6Qbx+tu+NcAcMvNDx9n9lXN2Yyrr6LEQNjd+eY+ yvY9pTo07MJ9ZirrKLwSb6CMBzHPLqboFomM1MnI/E+SuFZIxYcr/nc/9Qxz1mSX DALrXDVGHFANNRpSZykhB3BQp7WxPiy9CbdL8mMErP2yJt01h30+Qcm4Dh9imiI7 /QDmEAqSDHxtmXdvDmSbyFmU4X9jLJy3iE93FHYZxaeaRnlMOyIm34U7V9e54GfE oHAylj3paOX/7KP9AqoTfYhggYHg4svKWM54VzSnovlGLjoNQKI= =IYsu -----END PGP SIGNATURE----- --=-U7G+gF/AkXqWzvHrVjHi--