From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6444767352800149504 X-Received: by 10.223.133.1 with SMTP id 1mr844166wrh.19.1500539330004; Thu, 20 Jul 2017 01:28:50 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.20.66 with SMTP id 2ls646635lju.9.gmail; Thu, 20 Jul 2017 01:28:49 -0700 (PDT) X-Received: by 10.46.5.213 with SMTP id 204mr488413ljf.38.1500539329631; Thu, 20 Jul 2017 01:28:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1500539329; cv=none; d=google.com; s=arc-20160816; b=K+qToFin3K2V/YIx3J0mflvYOLVQh5kHzRT0nTXraW9i3tslGS1a4aJOqBuQ01g7/h FXpED2EKz+yYoqQoabiePgEYK2yLUCtFixLLIq8F82cw74iPy5SaIQ5mgGeWAh2QVIx2 pbN4/twLHPWDhPb47beumfngv1qX9IvMK81SSVrSh/MHiSjiOC8vbwmowaBfHx/LwmpM +HVnugZD0D4VGycw/BjGy213eRbdxCraOYOW3rvZxdU8u7wcWboyPJXfiVGnRbzKE+UN dyAh23G/IVyL3I5h/fNTD2mMKZPTk4OEIVF8eVd3AtJRnqK+Gz1DrMCHOLHJsAEXE3CT O2nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:message-id:subject:to:from :date:arc-authentication-results; bh=U8uzn46OoaRIMDw/ujUBL6qsHZhfJdH+qwKAeUsBEG4=; b=fxFav3//pckWa/OUUHCiWEBNDak7jbOEjYL6a9vkUM7toVvprRZk0lsJ3VaU5uwlfb MVGcifBXG+vO8DQ/7C4gh6kop7sEHRqJbC7PH67vTDwYwalzQz8UPBO2cTE+YHgT5oLk 8JBg2o02KGoj0nqfk/1xYAS62aSMtJJ8vXebg/mqhu6GVV48NkRBBsk+0APpVgBYwmXK UlaL6B3OJm5ww0kAL7wfM3dxCqeK2t0O599RcpYRf2L8VkgsLzic7vdo5Q6K3AE1O/Ft rRFgud7RHK2HPxSkzWNhR9+cmIzCij0rzZa28dzMbskUbq3jCxPtFWmCsQ+6a3AqvlP/ DqvA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 192.35.17.28 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id b190si561341wmd.8.2017.07.20.01.28.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 01:28:49 -0700 (PDT) Received-SPF: neutral (google.com: 192.35.17.28 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 192.35.17.28 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id v6K8SnfZ011451 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 20 Jul 2017 10:28:49 +0200 Received: from md1em3qc ([139.25.68.40]) by mail1.siemens.de (8.15.2/8.15.2) with ESMTP id v6K8SnBb001786 for ; Thu, 20 Jul 2017 10:28:49 +0200 Date: Thu, 20 Jul 2017 10:30:37 +0200 From: Henning Schild To: Subject: [RFC] can we just extend openembedded to get Isar 2.0 Message-ID: <20170720103037.794aab2e@md1em3qc> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: 80aUdS7F4vue 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