Re: [PATCH v3 1/3] dbus: merge .bb and .inc

[Patrick Ohly <patrick.ohly@intel.com>]

On Wed, 2015-12-02 at 16:47 +0000, Burton, Ross wrote:
> 
> On 2 December 2015 at 16:27, Patrick Ohly <patrick.ohly@intel.com>
> wrote:
>         I'm not sure about the "more complicated to do changes in
>         external
>         layers". Why is that?
>         
>         Quite the opposite, I found it useful that the version
>         independent build
>         rules (*) were in a .inc file and relied on including
>         that .inc file in
>         a "dbus-cynara" recipe which builds a specific fork of the
>         source code
>         [2].
>         
>         But I understand that this is an unusual usage of OE-core. As
>         I didn't
>         notice the change in time (it's in master now), I'll just copy
>         the
>         previous content of dbus.inc.
> 
> When a bb and an inc are split the inc has to be considered some sort
> of ABI.  For example, you couldn't remove a configure option that was
> removed in a new release from the .inc because older recipes that use
> the inc will still want it.  Then of course on new recipes that
> triggers a QA warning.  New options need to be added to the
> relevant .bb and not the inc, but then break if other users don't
> notice that they need to add options explicitly.  Basically the idea
> of bb/inc seems good, and in some situations is useful (multiple
> recipes maintained *in the same place* sharing common code) but as a
> method of re-using packaging it's got many pitfalls,

Thanks for the explanation, I understand now better why relying on
a .inc file is not recommended ;-) However, it remains unclear to me why
its presence makes changes in external layers more complicated. Based on
what you said, these external layers should completely ignore that there
is a .inc file and just work with the .bb file. I'm just curious whether
I'm still missing something.

> especially as your recipe could include the .bb from oe-core directly
> or be a bbappend.

In the layer I am trying to be compatible with OE-core master, dizzy,
fido and jethro. That means I cannot "require
recipes-core/dbus/dbus_1.8.18.bb" because that file only exists on
master.

It is possible to use a dbus_%.bbappend and then make changes based on
the current $PV (this is how some other differences between the OE-core
branches are handled), but that is not so easy for dbus-cynara because
it is not just modifying dbus. It's a new recipe.

I guess a virtual package created from the dbus recipe could work, but
that sounds way too complex compared to just copying the dbus.inc file.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.