Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

[Hongxu Jia <hongxu.jia@windriver.com>]

On 11/10/2014 02:42 PM, Martin Jansa wrote:
> The docs say that IMAGE_INSTALL is for "package_name". So I think it's
> correct that it fails when you put "recipe_name" in it and sometimes
> there isn't any package with the same name. It's the same as trying to
> make RDEPENDS/DEPENDS entries to be interchangeable (putting
> recipe_names to RDEPENDS and package_names to DEPENDS)."
>
> Especially with that patch for xinput-pointercal, if user explicitly
> asks for installing xinput-pointercal, what's the reason to create him
> completely empty package? IMHO it's only hiding that issue from him and
> instead of discovering the issue in do_rootfs task, he has to check
> generated rootfs or even boot the device.

For most recipes, they generate packages with recipe name, it is not
convenience to figure out the different between package_name and
recipe_name, especially for newbies, which I means we should reduce
that convenience, build relationship between recipe and package,
especially when the recipe doesn't generate the same name package.

As you said, for specific recipes, we don't want to generate packages,
it doesn't make sense to install it by setting IMAGE_INSTALL. But if the
recipe generate packages, it is reasonable to take one with recipe
name, take python3 for example, it choose python-core as the provider.

That's why I sent patch for avahi and oprofileui. The avahi didn't generate
package avahi, but it is reasonable to choose avahi-daemon, as the
SUMMARY said it is a IPv4 configuration daemon.

For oprofileui, it only generates package oprofileui-viewer, if we have
oprofileui as its nick name, I think it is more convenience for the users.

//Hongxu