Bug 2431

Summary: RRECOMMENDS and RDEPENDS are basically the same with opkg
Product: [Runtime] Package Management Issues Reporter: Andreas Oberritter <obi>
Component: ipkg opkgAssignee: Andrei Gherzan <andrei>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium CC: andrei, bluelightning, dvhart, meta.layer.watcher, meta.mr.watcher, meta.watcher, richard.purdie, shane.wang
Version: unspecified   
Target Milestone: 1.4   
Hardware: All   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---

Description Andreas Oberritter 2012-05-07 19:12:07 UTC
From the Poky reference manual (RRECOMMENDS):

"The Yocto Project build process automatically installs the list of packages as part of the built package. However, you can remove them later if you want."

This doesn't seem to be true with opkg. Packages can only get removed using --force-depends. Without this option, opkg remove fails.

I think this was caused by opkg SVN rev 556. Opkg behaved as expected at least with SVN rev 455.
Comment 1 Darren Hart 2012-05-16 22:59:37 UTC
Moving from Layers to meta-recipes as this affects the core as well.
Comment 2 Saul Wold 2012-08-14 09:44:55 UTC
This should be filed with the upstream bug, can you file the bug and provide the bug number here, it may still require us to patch and submit upstream.  Can you provide a good reproducer for this issue.
Comment 3 Paul Eggleton 2012-08-14 10:02:01 UTC
That's good in theory but I'm not sure there is an active upstream for opkg - if we want this fixed we will likely need to fix it ourselves.
Comment 4 Andrei Gherzan 2012-08-25 18:13:11 UTC
Andreas, please give me some more info about this - a way to reproduce this issue.

Thanks
Comment 5 Andreas Oberritter 2012-09-14 14:27:47 UTC
Use these steps to reproduce the issue:

1.) Build an image containing package A that RRECOMMENDS package B.
2.) Boot the image.
3.) Try to remove package B (opkg remove B).

Step 3 fails, because opkg treats the recommendation as a dependency.
Comment 7 Andrei Gherzan 2012-10-22 13:23:43 UTC
Merged to master.

ag
Comment 8 Richard Purdie 2012-10-22 13:33:09 UTC
Its merged to master-next, not master quite yet although its getting there...
Comment 9 Andrei Gherzan 2012-10-22 13:37:44 UTC
(In reply to comment #8)
> Its merged to master-next, not master quite yet although its getting there...

Correct. Sorry.