Re: [RFC] can we just extend openembedded to get Isar 2.0

[Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>]

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