[yocto] Layer model doomed, unless we all work together
Joe MacDonald
Joe_MacDonald at mentor.com
Wed Nov 19 19:34:41 PST 2014
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20141119/53981b26/attachment.pgp>
More information about the yocto
mailing list