[yocto] Layer model doomed, unless we all work together
Joe MacDonald
Joe_MacDonald at mentor.com
Thu Nov 20 07:59:51 PST 2014
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
-------------- 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/20141120/e56bac5f/attachment.pgp>
More information about the yocto
mailing list