Re: Layer model doomed, unless we all work together

[Joe MacDonald <Joe_MacDonald@mentor.com>]

[-- Attachment #1: Type: text/plain, Size: 5133 bytes --]

Hey Philip,

[[yocto] Layer model doomed, unless we all work together] On 14.11.18 (Tue 16:28) Philip Balister wrote:

> As evidence, please review this list:
> 
> http://layers.openembedded.org/layerindex/branch/master/duplicates/
> 
> I mean FOUR recipes for alsa-plugins?
> 
> I am trying to fix the pyqt recipe in meta-oe, and had th eidea to check
> for it in other layers. This leads me to meta-ivi-demo, which has an
> update for sip-native and another pyqt recipe. To be fair, they are
> using Qt5, so it is a little more complex.
> 
> At any rate, we need to stop ripping recipes out of layers and maing
> local copies, or worse, updating our local copies and not the primary
> layer. The intent of the layer concept was not to fragment development
> across many separate repositories.

I completely agree and I'm glad you brought it up.  I'm all for doing
what I can to help on this.  I also second Ross' suggestion, perhaps we
could start working on an implementation of RFC5841 as a first phase,
though I'm thinking that may not be the healthiest thing for me.  :-)

> I see a couple of issues we need to start talking about:
> 
> 1) recipes that need to move closer to core because a range of other
> packages use them.

This was actually the only thing I thought needed further discussion
(everything else should largely be a nod-in-agreement thing), as in some
cases I'm not sure it's always clear what constitutes "closer to the
core".  Poky and oe-core layers are pretty clear, but the next step
beyond that isn't.  Are all layers hosted on git.yoctoproject.org
inherhently "more core" than layers on git.openenbedded.org?  And
there's a number of shells when you start including all of the github
projects, setting aside other open-source project hosting services.

Looking at the link you sent out based on Paul's suggestion, I see I'm
actually on both sides of this equation, so yay!  And I'll limit the
discussion to what's indexed there.

Here're my examples.

iscsi-initiator-utils: both in meta-networking nd meta-openstack.  Both
at the same version currently but wildly different contents.
meta-openstack is a git.yoctoproject.org project, so does that make it
closer to the core?  I would think not, but as I recall there had been
some comment about the openstack layer intending to limit layer
dependencies outside Yocto core when it first appeared, so maybe making
meta-networking a dependency is a non-starter for them.

That said, I feel sorry for Alex's meta-cgl layer since it looks like it
uses both meta-networking and meta-openstack and bbappends to
iscsi-initiator-utils, which have significantly different patch sets.
It hasn't bitten me in any of my testing with meta-cgl yet, but I didn't
even notice this before now and I wasn't testing iscsi.  I would not be
at all surprised if different people have different results using iscsi
with meta-cgl now.

On the other side of the coin is the swig recipe in meta-selinux and
meta-oe.  The selinux build requires swig, so the meta-selinux layer
needs to know it is there.  I was actually gearing up a while back to
ditch the swig recipe in meta-selinux since it was so old and obviously
behind the meta-oe version, but didn't ... for reasons that now escape
me but could have been "because that would make meta-selinux depend on
meta-oe", which isn't necessarily a dependency we wanted to bring in for
meta-selinux.  But I'm highly allergic to duplicating (and inevitably
diverging) data, so I'd still like to kick swig out of meta-selinux.
But I also almost never build meta-selinux projects without some of
meta-oe kicking around too.  Maybe that's everyone who uses
meta-selinux, I don't know.

Anyway, just to keep it really interesting, is meta-selinux and
meta-security, both including recipes for libcap-ng, both at the same
version, both different again (though not nearly so bad as the example
above).  Which of these is more core?  I honestly don't know, since I
have used them together and separately on roughly equal number of
projects and I expect that trend will continue for a good long while for
me.  I think this might be a scenario where meta-selinux and
meta-security could make a case for trying to push this recipe further
toward the core.

Also, in light of this discovery, I'll be sending a patch for
meta-security soon, since the meta-selinux changes for libcap-ng are
almost certainly wanted there too.  But that's neither here nor there.

> 2) people feel they have to remove recipes from layers and make local
> copies.
> 
> And just so people know what seriously pisses me off :) Copying a recipe
> from a layer, updating it, and not sending the recipe to the layer they
> got the update from.

I don't know if that's what has happened with any of the recipes in the
layers I baby-sit, but if it is, it was absolutely not intentional and
I'll see what I can do about recovering a bit of karma by tidying up
about the place a bit.  :-)

-J.

> 
> Thanks for letting me vent,
> 
> Philip
-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]