From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6444767352800149504 X-Received: by 10.25.23.36 with SMTP id n36mr544900lfi.39.1500542111500; Thu, 20 Jul 2017 02:15:11 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.84.10 with SMTP id i10ls646439ljb.3.gmail; Thu, 20 Jul 2017 02:15:11 -0700 (PDT) X-Received: by 10.46.20.3 with SMTP id u3mr498900ljd.43.1500542111145; Thu, 20 Jul 2017 02:15:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1500542111; cv=none; d=google.com; s=arc-20160816; b=F/rnKDe3qZreD2iuNwAHvAV8AI584/ugaTLu6zM+I2i+JVZJUgWbEzxAjyfWpQzRl0 JPgog6rB5G4iIIpxJ7w3ywJxCL4HiAT+h+uDp6rmMmiwsV1Am7VTQo+oYZoD62h4FaE0 ahWLgO78eV+lXt51uzzX5So+3tULw6Bp+L5RnieRgctsyOaEu+Z/fxHylO+d4ExUKpch +B4ODOpacb6Y2QXkdC885x+w5E4HJ+rhQM2HTQETvhQ+G3vG0z5AO8CS98RbegMsTL+0 qHSmdy6YoHWsNH4rovCdGWidt877dlaTiBcj3k+zEyAMlkQlO+enQqegvpChWkNbf2IN nqcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :arc-authentication-results; bh=oZ6fi8yavyHqWeMZg3vgMLH5vqYeN+psdWWRO7i8CcY=; b=GvlrWBkHAU9bru822pDKlvGpOnPJ6OqJlxD4IK6G0QFA0ZIIqwET5sUo4GY6Nu/obw 6qi38dpG47zWAcFPjxP5LNKeqbEYWk1a7xLWMZlEIiEATVH7Gt5aSuRthPo7zqG3BVhS 9zYRzmdU7h+JsAYxm8fpPCy87HA/4Oh6WnSm7rVXBNjkT1+Ugc7IAQEO3KhX7mK0Kuxj 9gw8FZBwqB0VXGo2UOClg6UEBE/xsPHrUQ67KsO60z1wCXvGYi7lxoq6hCEZijpWKn8F hdqulEDlfhsV5fEzcQdyrUNQ0I5pTkx/ztpikcrAZ7HgDhGaScEjFUHPf1NdpnV30tI4 9jCw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 192.35.17.14 is neither permitted nor denied by best guess record for domain of jan.kiszka@siemens.com) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id f15si586424wmg.2.2017.07.20.02.15.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 02:15:11 -0700 (PDT) Received-SPF: neutral (google.com: 192.35.17.14 is neither permitted nor denied by best guess record for domain of jan.kiszka@siemens.com) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 192.35.17.14 is neither permitted nor denied by best guess record for domain of jan.kiszka@siemens.com) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id v6K9FAZ8002539 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 20 Jul 2017 11:15:10 +0200 Received: from md1f2u6c.ww002.siemens.net ([139.22.142.125]) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id v6K9F95J012151; Thu, 20 Jul 2017 11:15:09 +0200 Subject: Re: [RFC] can we just extend openembedded to get Isar 2.0 To: Henning Schild , isar-users@googlegroups.com, Baurzhan Ismagulov , Alexander Smirnov , KOBAYASHI Yoshitake , Daniel Sangorrin References: <20170720103037.794aab2e@md1em3qc> From: Jan Kiszka Message-ID: Date: Thu, 20 Jul 2017 11:15:09 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <20170720103037.794aab2e@md1em3qc> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: Pe/yh+2nII+F 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