[oe] Splitting meta-oe?

[Joe MacDonald]

[Re: [oe] Splitting meta-oe?] On 18.02.21 (Wed 09:20) Tom Rini wrote:

> On Wed, Feb 21, 2018 at 09:02:53AM -0500, Joe MacDonald wrote:
> > [Re: [oe] Splitting meta-oe?] On 18.02.21 (Wed 11:22) Martin Jansa wrote:
> > 
> > > There is good example of inter-layer dependencies from real world:
> > > http://lists.openembedded.org/pipermail/openembedded-devel/2017-February/111447.html
> > > 
> > > Do you want
> > > A) new git repository meta-libio-socket-ssl-perl so that meta-networking
> > > will depend on this on instead of whole meta-perl
> > > B) meta-ddclient which will probably depend on both meta-perl and
> > > meta-networking
> > > C) ddclient and its dependencies in meta-perl
> > > D) libio-socket-ssl-perl moved to oe-core, so that next time we can say
> > > that oe-core is just like old oe-classic just with a bit less stuff in it
> > > 
> > > Neither of these options is ideal, but meta-networking getting meta-perl
> > > dependency is the one which causes fewest issues to OE users.
> > 
> > Yeah, I've been thinking about this and trying to decide what is the
> > "right" thing to do here.  Because I already have added layer
> > dependencies in meta-networking that I didn't originally envision, so
> > what's one more that is, as you say, almost certainly in the majority of
> > consumers' projects anyway?  But it does force a new layer dependency on
> > consumers of the meta-networking layer who may not care about ddclient,
> > and I'd like to avoid that if possible.
> > 
> > Honestly, now that I'm back from my vacation, I think the right thing is
> > to add the dependency and then start thinking about a way to specify
> > layer dependencies with greater granularity than on a meta-layer basis.
> > Like, there's no question meta-networking depends on core.  It's
> > nonsense to think of it without that dependency.  But it'd be nice to be
> > able to specify a layer dependency that only exists if your project
> > includes specific recipes out of that layer.
> > 
> > But that kind of mechanism seems highly prone to breakage and likely to
> > be highly contentious even if it was shown to be reliable, so it may not
> > get beyond a "that'd be nice" thing for me.
> > 
> > Unless someone else has already implemented it and I'm just not aware of
> > how to use it?  :-)
> 
> One thing I've been thinking about is that some layers need more
> sub-layers.  Taking a very tiny peek into meta-networking, perhaps
> re-organize into meta-networking-core, meta-networking-iscsi,
> meta-networking-vpn, etc.  Or maybe that won't help with dependencies.
> But the need for layer X for a single recipe can sometimes I think be
> solved by re-thinking the layer.

I really like that idea.  We effectively started that with the netkit
stuff when Armin first submitted it, so making it more formal isn't a
big step anyway.

> All that said, it might be better instead to add something like
> RECIPE_LAYERDEPENDS so that for the one-or-two offs, the recipe will
> fail to build (and implement that similar to the logic in
> image-container.bbclass? so that you only get a failure on building that
> recipe rather than anything in the layer) ?

Yeah, that's kind of what I'd been thinking.  In the short term, though,
the reorg you suggested above sounds *very* appealing to me at first
glance.  Might be a "let's do both" situation.

-- 
-Joe MacDonald.
:wq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20180221/80f88c75/attachment-0002.sig>