Re: [OE-core] [meta-oe][PATCH v4 1/3] introduce lib_subpackage

["Phil Blundell" <pb@pbcl.net>]

On Fri, Dec 04, 2020 at 08:30:01AM -0500, Sinan Kaya wrote:
> +Richard,
> 
> On 12/4/2020 6:01 AM, Phil Blundell via lists.openembedded.org wrote:
> > On Thu, Dec 03, 2020 at 11:28:24PM +0000, Sinan Kaya wrote:
> >> This subclass allows us to easily split a recipe into
> >> subpackages.
> > 
> > "lib_subpackage" seems a slightly odd name for something that isn't
> > dealing with libraries.  What's the etymology of that?
> 
> I'm open to giving it a better name. Richard pointed me to a file
> beginning with lib_foo.class for where this functionality could be
> hosted before.

I suppose the interesting question here, then, is "what is this class
actually for?"  The description above says that it "allows us to easily
split a recipe into subpackages" but doesn't say very much about what
the consequences of including the class actually are or under what
circumstances that's useful.

Reading between the lines the idea seems to be that this class is
appropriate for recipes that build a collection of utilities each of
which is essentially independent and is useful in its own right
without any of the others.  Is that right?

> >> +    d.appendVar("PACKAGES", " " + " ".join(packages))
> >> +    d.appendVar("PROVIDES", " " + " ".join(packages))
> > 
> > It seems a bit strange to be putting the same things in PACKAGES and
> > PROVIDES.  Is that actually necessary?
> 
> I want to be able to include procps-ps without the entire procps
> package. I was not able to do that without the above two lines.

What do you mean by "include procps-ps"?  It sounds like you're saying
you want to be able to introduce procps-ps to DEPENDS, is that right?

p.