Hello Leandro,
On 16.06.2015 20:20, Leandro Dorileo wrote:
> On 05/13/2015 07:41 PM, Andreas Oberritter wrote:
>> Hello Bruno,
>>
>> On 13.05.2015 23:51, Bruno Bottazzini wrote:
>>> +########################################################################
>>>
>>> +# Aggregation of Split Packages
>>> +########################################################################
>>>
>>> +PACKAGES =+ "${PN}-services-base"
>>> +SUMMARY_${PN}-services-base = "Base services aggregation"
>>> +ALLOW_EMPTY_${PN}-services-base = "1"
>>> +RDEPENDS_${PN}-services-base = " \
>>
>> I think it would be better to use RRECOMMENDS, in order to support
>> BAD_RECOMMENDATIONS per image. This would also remove the need to use
>> bb.utils.contains, because unavailable recommended packages get ignored
>> by the package managers.
>
>
> In the end, isn't it just a different approach? a different way of
> doing the same thing?
No. Although recommended packages get installed by default, just like
depended-upon packages, the difference is that you can choose to
uninstall these packages selectively or to disable automatic
installation using "BAD_RECOMMENDATIONS".
If you choose this route, then it doesn't make a difference whether you
use bb.utils.contains(...) for each package or not when declaring the
relationship between packages (unless you keep old packages on your
update feeds). I just mentioned that, because the patch is already hard
to read and any simplification in syntax may be a plus. I don't think
it's important though.
> By the way, from my point of view, semantically
> we're saying "we want a given package feature" besides the "we want a
> given distro feature", don't you think?
I can't follow you, sorry. At this point, PACKAGECONFIG already
determined which files got built, installed and packaged. I fail to
connect this to distro features in this context, besides its use for
sane defaults of the PACKAGECONFIG variable.
Regards,
Andreas
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
