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

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2690 bytes --]

On Mon, Nov 10, 2014 at 10:02:47AM +0800, Hongxu Jia wrote:
> On 11/09/2014 02:53 AM, Koen Kooi wrote:
> >> Op 7 nov. 2014, om 15:38 heeft Martin Jansa <martin.jansa@gmail.com> het volgende geschreven:
> >>
> >> On Fri, Nov 07, 2014 at 03:57:01PM +0800, Hongxu Jia wrote:
> >>> The package avahi does not exist, so we use avahi-daemon as the provider.
> >>> It avoids the do_rootfs failure while IMAGE_INSTALL += "avahi"
> >> Why don't you fix your IMAGE_INSTALL instead?
> > I agree with Martin, this is a non-problem, please fix your IMAGE_INSTALL.
> 
> I am afraid it is not the issue of IMAGE_INSTALL
> 
> As doc said:
> http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#var-IMAGE_INSTALL
> Variable IMAGE_INSTALL is used to specify the packages to install into 
> an image.
> 
> While adding some packages to image ,the rpm based do_rootfs
> failed with '*** not found in the base feeds'
> 
> The failure was caused by two kinds of situations:
> 1. Package does not exist (such as python3), but provided
>     by other package (such as python-core), the rpm based
>     do_rootfs could not search its provider. And the deb/
>     ipk based do_rootfs worked well, it is a defect, and
>     I have fixed it (patch sent to community, YOCTO 6918);
> 
> 2. Package does not exist, and no other package provides it,
>     the package installation will fail in any type do_rootfs. We
>     met this issue when we set IMAGE_INSTALL = "recipe_name",
>     but we don't have the package with that name.
> 
> I think what I do is to fix the situation 2.
> 
> Further more, we should add checking at the package generating
> time, if the package *with recipe name* was empty and not created,
> trigger a warn and according the warn, we could fix the issue recipes.

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.

> We already have that checking at the package generating time,
> but it a note, not warn. I suggest we should use warn instead.
> 
> //Hongxu
> 

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]