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

["Sinan Kaya" <okaya@kernel.org>]

On 12/5/2020 5:23 PM, Phil Blundell wrote:
>> 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?

Yes, this is correct.

> 
>>>> +    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?
> 

I want to be able to include a specific tool out of N number of tools
that a package builds into the image.

> p.