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.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145335):
https://lists.openembedded.org/g/openembedded-core/message/145335
Mute This Topic: https://lists.openembedded.org/mt/78698208/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
