Hi Paul, [Re: [yocto] Layer model doomed, unless we all work together] On 14.11.20 (Thu 13:43) Paul Eggleton wrote:
> On Wednesday 19 November 2014 22:34:41 Joe MacDonald wrote: > > [[yocto] Layer model doomed, unless we all work together] On 14.11.18 (Tue > 16:28) Philip Balister wrote: > > > 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. > > The answer to me there is certainly not. I've said this recently in other > discussions, but I'll say it here anyway in case anyone else isn't sure - > layers on git.yoctoproject.org should not be considered in any way more > official > than anywhere else solely based on them being hosted there. Anyone who wants > to maintain and publish a layer suitable for others to use can get a > repository on git.yoctoproject.org - there's no official review, validation, > or > acceptance criteria in the general case just for having a repository there > (beyond being related to the project, that is). That certainly makes sense to me, though I can respect if a project maintainer wanted to try to keep everything they put there contained to other projects hosted there. Probably that's not even the case now, I've not looked, but if I were starting a layer that I wanted to be dependent only on, say, oe-core, and it was still useful to the community at large, I would consider git.yoctoproject.org to be the most sensible place to host it. Regardless, I think your clarification makes perfect sense. > To me this isn't so much about "closer to the core", it's about: > > 1) sensible recipe groupings, e.g. meta-networking rather than a particular > project's mixed recipes layer > > 2) good maintenance, i.e. recipes are semi-regularly updated when upstream > releases happen, fixed when needed to accommodate changes that happen in > other > layers it depends upon such as OE-Core, and the maintainer is reasonably > responsive to patches or questions relating to the layer. > > We need both of those things to encourage re-use, and if we have both then it > doesn't really matter where a layer is hosted as long as it's listed in the > layer index. Fair enough. Though I do think that a natural consequence of the groupings in #1 above would tend to have recipes that appear in multiple project's mixed recipe layers move toward the core. But I also agree that it needs to make sense for the layers involved. > > 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. > > So I've talked to Bruce about meta-openstack before, with particular regard > to > the number of python recipes that the layer ships and future overlap with > meta-python, and apparently the policy there is not to pull in other layers > for some dependencies with the aim of avoiding breakage on upgrades. I don't > like that very much at all, to be frank, but I can at least understand it > given how huge OpenStack is. It does of course mean that the overlap with > that > layer in particular is only going to increase as time goes on. Hmm. Okay, I don't want to veer too far off the topic, but what I'm getting from this is that meta-openstack is a layer usable for building OpenStack, but otherwise probably isn't an ideal base for other layers. There's two obvious points of divergence between meta-networking recipes and meta-openstack ones, both of which have the same priority, and it sounds like there's going to be an increasing number of these with meta-python. I don't know that, given how large OpenStack is, adding other layer dependencies would amount to more than a drop in the bucket, but as a philosophical discussion rather than a technical one, I'll stick to knowing to regularly check the index and time I'm looking at recipes or working with a new layer. That's probably really good advice for anyone, honestly. That's for the info, Paul. -- -Joe MacDonald. :wq
signature.asc
Description: Digital signature
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto