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
signature.asc
Description: Digital signature
-- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
