Created attachment 2397 [details] Patch to change packaging of eglibc-utils -> libc-utils, triggering this bug if a packagegroup uses ${LIBC_DEPENDENCIES} This is point 1 from Bug 5970, but has just bitten me again: When the packaging of a recipe is changed in a way that causes debian.bbclass to rename a package, any packagegroups that reference this package must be rebuilt, but http://git.openembedded.org/openembedded-core/commit/?id=80b065ff46322ec0cad039dfd9eb2d010168dba6 prevents them from being rebuilt. In my case that happened when I tried to modify eglibc's packaging to improve license metadata by separating ldconfig (which is GPL-2+) into a separate package. The change simplifies checking for license compliance, because the libc6 package is LGPL-2.1+, which does not have a strong copyleft. Attached is a patch you can use to reproduce the problem (you'll have to write the packagegroup yourself, but that's really trivial). The problem occurs because the libc6 package no longer contains binaries and debian.bbclass thus renames all packages generated by the recipe, e.g. from eglibc-utils to libc-utils. I'd argue the overhead of rebuilding the package groups is small, but the impact of a problem like this is large when it occurs, so 80b065ff46322ec0cad039dfd9eb2d010168dba6 should be reverted or improved to deal with this case correctly. Note that the current master adds "and isAllArch(fn)" to the condition that causes this, but still seems to be affected.
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.
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=0562ab65936a11217cad570d4d633a246e20d3c6
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?