From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6444767352800149504 X-Received: by 10.200.44.23 with SMTP id d23mr2924557qta.87.1501161274410; Thu, 27 Jul 2017 06:14:34 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.107.21.2 with SMTP id 2ls1927745iov.21.gmail; Thu, 27 Jul 2017 06:14:34 -0700 (PDT) X-Received: by 10.101.89.6 with SMTP id f6mr3044249pgu.74.1501161274039; Thu, 27 Jul 2017 06:14:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1501161274; cv=none; d=google.com; s=arc-20160816; b=0E9oL8vvvTkWl8riWFFntjJVVNNpzteR+oiKMzZPdo6AqQEFyaWIw3bBAOYK3yoNG5 F+tLXBrgvMRNHhf84SvbcC0edHaI6/ZpYmO1ZhrjUcw9Fg4/793O5FNveriz1WvshWeA 4D7lPmAmZGetC9hEPmcTfp/pc9GOOyMFl9wf34lHhHG4bl00Va4losQieq08C5Rj3vnG 3LjE7ot2wMF/dtMXGJ3rgAg/Few41C6lrIn37hXA4Ovb/90+WZLFUfhKWR2Xh65n5aQQ LJS1L9jJQahNpikiRDoHjgMnK9aKq0h3W30vJyF28Wwt/r6KBmDAWlJBYirk/43PMGBi X9Ug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:arc-authentication-results; bh=D8Bap2WgDiDCXbmrDH2GECKzkCydR6oXPA+Ane0p69w=; b=jIP4A5M1T1cnQ7Jg3WwdrazxTrmAfJpuyD84MWj9gqqTlU7r9NU8dFmzEo4u+hFQNM K5BtC1626wd0XK5L2ooxcEXnFbXCFEbhuUMa3ti0gBgYcMlqOJjd0Moj+AtHY6yc3c7q HOuUp1SrdyVrjilVj1vJpFGQwg1BKV+K0jMCka/35pABaog2VqCQYd4VXFPRXVvpvP1e A8YkEXqRC2ook2CyQ2IgxA8nwiFRkrfshTQpYb+uFkVGI2ttCD7cj2dqMFgwWoX4aGsf wN4w/InD+4gCB6xIKWw+dwg3wV5JciFmstvGNJf9FEHwsuoTNqZ8go57phIZfnD1aC9g xofg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of kazuhiro3.hayashi@toshiba.co.jp designates 210.149.48.173 as permitted sender) smtp.mailfrom=kazuhiro3.hayashi@toshiba.co.jp; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=toshiba.co.jp Return-Path: Received: from mo.tsb.2iij.net (mo1501.tsb.2iij.net. [210.149.48.173]) by gmr-mx.google.com with ESMTPS id 71si3787564pfn.17.2017.07.27.06.14.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jul 2017 06:14:33 -0700 (PDT) Received-SPF: pass (google.com: domain of kazuhiro3.hayashi@toshiba.co.jp designates 210.149.48.173 as permitted sender) client-ip=210.149.48.173; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of kazuhiro3.hayashi@toshiba.co.jp designates 210.149.48.173 as permitted sender) smtp.mailfrom=kazuhiro3.hayashi@toshiba.co.jp; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=toshiba.co.jp Received: by mo.tsb.2iij.net (tsb-mo1501) id v6RDEPRE013328; Thu, 27 Jul 2017 22:14:25 +0900 Received: from unknown [172.27.153.190] (EHLO tsb-mr1502.hop.2iij.net) by mas1505.tsb.2iij.net(mxl_mta-7.2.4-7) with ESMTP id 137e9795.0.60976.00-696.121556.mas1505.tsb.2iij.net (envelope-from ); Thu, 27 Jul 2017 22:14:25 +0900 (JST) X-MXL-Hash: 5979e73108eb7d05-1311a98f04142065849ef6da075cae96a4ea1da3 Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by relay.tsb.2iij.net (tsb-mr1502) with ESMTP id v6RDEOd2008781; Thu, 27 Jul 2017 22:14:24 +0900 Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id v6RDEOvS001668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jul 2017 22:14:24 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id v6RDEOXr025169; Thu, 27 Jul 2017 22:14:24 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 1000; Thu, 27 Jul 2017 22:14:24 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id v6RDEOF3025166; Thu, 27 Jul 2017 22:14:24 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id v6RDEOGt025479; Thu, 27 Jul 2017 22:14:24 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id YAA25478; Thu, 27 Jul 2017 22:14:24 +0900 Received: from mx2.toshiba.co.jp (mx2 [133.199.192.142]) by ovp11.toshiba.co.jp with ESMTP id v6RDEO8t014895; Thu, 27 Jul 2017 22:14:24 +0900 (JST) Received: from BK2211.rdc.toshiba.co.jp by toshiba.co.jp id v6RDEN5Y005950; Thu, 27 Jul 2017 22:14:23 +0900 (JST) Received: from vmkw1204.swc.toshiba.co.jp (localhost [127.0.0.1]) by BK2211.rdc.toshiba.co.jp (8.13.8+Sun/8.13.8) with ESMTP id v6RDENAd015448; Thu, 27 Jul 2017 22:14:23 +0900 (JST) Received: from [133.196.174.136] (unknown [133.196.174.136]) by vmkw1204.swc.toshiba.co.jp (Postfix) with ESMTP id 51A79C043F; Thu, 27 Jul 2017 22:14:23 +0900 (JST) Subject: Re: [RFC] can we just extend openembedded to get Isar 2.0 To: isar-users@googlegroups.com, "[ext] Jan Kiszka" , asmirnov@ilbers.de, Claudius Heine , Henning Schild , KOBAYASHI Yoshitake , Daniel Sangorrin , Claudius Heine References: <20170720103037.794aab2e@md1em3qc> <20170720230529.GB5040@yssyq.radix50.net> <844d35a9-6ffd-9a84-b324-21acec937eaf@siemens.com> <20170724225350.GC3612@yssyq.radix50.net> <98c6b5a8-d428-5116-84fe-4342177c8af3@siemens.com> From: Kazuhiro Hayashi Message-ID: <20bd9141-aa4c-2211-2c0b-b5294c971133@toshiba.co.jp> Date: Thu, 27 Jul 2017 22:14:23 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <98c6b5a8-d428-5116-84fe-4342177c8af3@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-MAIL-FROM: X-SOURCE-IP: [172.27.153.190] X-Spam: exempt X-TUID: 0GV4cq3KT70p Hello, >>>>> The problem with Debian support in OE is that it is very undebian. Debian has >>>>> its strengths, and there are reasons why Debian developers strongly dislike OE >>>>> (see e.g. [1], and I've heard many such discussions). Deby / meta-debian >>>>> follows the OE way of building Debian packages, and currently considers moving >>>>> to the Debian way. The reason is, as soon as you oeize a package, you have to >>>>> maintain it. That is why Isar does things the Debian way and aims at avoiding >>>>> massive package modifications; OE doesn't really help here. >>>> >>>> The idea is not to move to the OE way of doing Debian, for sure. It's >>>> about adding the right way to the OE-core tools and libs that are useful >>>> or even mandatory for Isar instead of forking or reimplementing them now. >>> >>> The idea is clear, the answer is above: The adjustment effort is the same. We >>> want to merge upstream, we don't reimplement. >> >> So far, we do reimplement (which includes code snippet imports). In Deby, there are more than 700 recipes (.bb) and all of them are implemented following OE-Core way. As Baurzhan mentioned, the main issue is to create and maintain such recipes ourselves. On the other hands, as an advantage, the recipes can reuse (inherits) most common stuffs like .bbclass, .conf, etc. provided by OE-Core without any changes. Examples: * Tasks for cross-building own kernel (kernel.bbclass) * Functions to run menuconfig through bitbake (cml1.bbclass) * ptest infrastructure (ptest.bbclass) * Packaging functions (package_deb.bbclass) * Recipes for generating rootfs and SDK (core-image-minimal.bb, meta-toolchain.bb) * sstate caching (sstate.bbclass) IIUC, most .bbclass depend on OE-Core infrastructure (some of them depend on metadata as well). For examples, they add several recipes (especially native recipes) provided in OE-Core to their DEPENDS, assume the default task flow (do_configure, do_compile, etc.), cross toolchain and sysroots of OE-Core. To split such OE-Core dependent stuffs from existing .bbclass (or to adjust them for other system like Isar) may require much effort. Additionally, big issues we met are: * There is no efficient way to append .bbclass * Specification of such kind of common stuffs frequently change in upstream Regarding libraries (meta/lib), I've never tried to reuse or inherit classes or functions in them, but I guess that they have less dependencies on OE-Core infrastructure and metadata than .bbclass. Some of them get values from several global variables define in the default configs (.conf) in OE-Core. Regarding scripts, we are just users, no experience of customization. As Baurzhan mentioned, Deby is now considering moving to the Debian way, but this change affects only how to implement .bb for Debian packages. In other words, we will keep using OE-Core infrastructure as before under the following policies. * Manage all files (.bb, .bbclass, .conf, etc.) in an independent layer (meta-debian.git) which works on top of OE-Core * Don't modify (fork) OE-Core layer, instead, adjust by overriding variables Actually, due to the above reasons, there might not be so many existing stuffs, which can be shared with Debian way, in OE-Core (except bitbake). At least, supporting sysroot and adapting Debian toolchain to OE-Core are required to reuse most existing .bbclass. We are just considering the better solution to implement Debian way on top of OE-Core infrastructure, including such wide adaptation. Best regards, Kazuhiro -- Kazuhiro Hayashi E-mail: kazuhiro3.hayashi@toshiba.co.jp