Bug 7714

Summary: poky bitbake: RRECOMMENDS_${PN} treated as runtime dependency
Product: [Build System, Metadata & Runtime] BitBake Reporter: Willem <willem.romkes>
Component: bitbakeAssignee: Richard Purdie <richard.purdie>
Status: RESOLVED NOTABUG QA Contact:
Severity: minor    
Priority: Undecided CC: bluelightning, poky.bs.watcher, poky.watcher
Version: unspecified   
Target Milestone: ---   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know
Attachments:
Description Flags
Patch
none
Patch none

Description Willem 2015-05-04 13:19:22 UTC 
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)
Comment 1 Willem 2015-05-04 13:24:48 UTC 
Created attachment 2489 [details]
Patch
Comment 2 Paul Eggleton 2015-05-07 14:25:13 UTC 
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.
Comment 3 Richard Purdie 2015-05-07 15:19:53 UTC 
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.
Comment 4 Willem 2015-05-08 05:36:24 UTC 
(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.