Created attachment 2488 [details] Patch RRECOMMENDS_${PN} is treated as RDEPENDS_${PN}. As far as I understand: - RDEPENDS_${PN} is a hard runtime dependency (i.e. it must be available) - RRECOMMENDS_${PN} is a soft runtime dependency (i.e. it would be nice if available) Refer to file http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/taskdata.py, function add_tasks, section #: for package in rdepends: for rdepend in rdepends[package]: rdependlist.append(rdepend) rdependids[self.getrun_id(rdepend)] = None for package in rrecs: for rdepend in rrecs[package]: rreclist.append(rdepend) rdependids[self.getrun_id(rdepend)] = None Recommended package in rrecs are saved to the rdependids list... I am in no way an expert on the bitbake internals. I created a patch that does the trick (see attachment) but probably I'm missing some extra modifications an expert would come up with instantly (or I'm completely on the wrong track). Attached patch is based on poky c4f1f0f491f988901bfd6965f7d10f60cb94a76f (daysy-11.0.1)
Created attachment 2489 [details] Patch
The intended behaviour is that there must be something claiming to provide something in RRECOMMENDS, so if nothing does then an error is expected - it's just that whether or not that dependency really gets satisfied at runtime is optional. So I think it's working as designed at the moment.
Bitbake itself requires dependencies to be resolvable. We can do fuzzy patching with things like PACKAGES_DYNAMIC which is a mask of packages that can be generated but to bitbake we need to have a way that something can possibly get built. The other issue is that we support dependency renaming. In order to do this and get the dependencies right, we need a dependency tree which is complete, not where pieces can get added in later (e.g. through addition of a layer). So I think our user experience would significantly deteriorate if we did this and the patches are not acceptable. The optional nature of RRECOMMENDS is at runtime and at the package manager level, not the build system.
(In reply to comment #2) > The intended behaviour is that there must be something claiming to provide > something in RRECOMMENDS, so if nothing does then an error is expected - > it's just that whether or not that dependency really gets satisfied at > runtime is optional. So I think it's working as designed at the moment. (In reply to comment #3) > The optional nature of RRECOMMENDS is at runtime and at the package manager > level, not the build system. If only the package manager needs to know what packages are recommended, why does the build system complain if the specified package isn't available? The package should be able to build without it. IMHO the only action from the build system I would expect is to check if a recipe for that package exists in the meta. (Well, in case of building a dedicated system that is. In case of building a distro like Ubuntu you just want to build the recommended packages too...) Anyway, thanks for your time gentlemen.