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 <[email protected]> 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: [email protected]
signature.asc
Description: Digital signature
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
