| Summary: | packagegroups are not rebuilt when rdependency pkg name changes | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Clemens Lang <clemens.lang> | ||||
| Component: | configuration | Assignee: | Richard Purdie <richard.purdie> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium | CC: | alex.kanavin, JPEWhacker, mikko.rapeli, randy.macleod, ross.burton, samuli.piippo | ||||
| Version: | 1.6.2 | ||||||
| Target Milestone: | 4.99 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | Don't know | |||||
| Attachments: |
|
||||||
|
Description
Clemens Lang
2015-02-06 13:57:35 UTC
The trouble is the packagegroups are allarch and if we want to make them depend on the packaging relationships, the only option we'd have would be to make them all machine specific, meaning they'd be replicated for each individual machine. I've left this bug open for as long trying to think of some other way to deal with this, but as yet, I've not been able to. I will say that I'm not particularly happy with a number of problems the debian renaming causes though and have been considering specifically encoding the debian renaming in the recipes rather than dynamically generating it as its done today... We have also just hit this issue: there is a packagegroup that includes a 'somelib' that gets debian-renamed to 'libsomelib6'. When an update to somelib recipe causes the renaming to change to 'libsomelib9', packagegroup isn't updated as it should be. A quick fix would be to not include the library into the packagegroup (it should be pulled in by depenendecies), but people were wondering why this doesn't jsut work, and doubting the sstate cache mechanism etc. While there are ways of dealing with this, the problem is relatively rare and the solutions are likely fairly complex so there is no plan to work on this issue. It's hard to identify the 'libsomelib6' class of packages so we can't even warn about them being present in a packagegroup in say a sanity check. If you have an idea other than reverting the commit mentioned, please say so. I believe this may have been fixed by https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=87c9d29 I'm not sure if this "undoes" things such as debian package renaming or kernel package renaming in cases where we need it. I think the original plan here is to add checking to allarch packagegroups that all the rdepends/rrecommends don't have PKG_ renaming active. Those that do have this would show an error asking the user to mark them as machine specific. That would allow us to revert the fix linked to by Joshua and properly fix the underlying issue. I've sent out a patch which does what I suggested above and checks allarch packagegroups aren't using PKG renaming, throwing an error if they are. I think that should be as good a compromise as we'll get with this bug. The sanity check now barks at nativesdk packagegroups for being allarch even though allarch is never applied to those. Also the check now seem too eager, as with the change Joshua mentioned, the dependencies should already be using the original pkg name. Could the sanity check verify that pkg is not in RPROVIDES section to avoid false positives? |