7298 2015-02-06 13:57:35 +0000 packagegroups are not rebuilt when rdependency pkg name changes 2021-11-16 15:12:38 +0000 1 1 7 Build System, Metadata & Runtime OE-Core configuration 1.6.2 x86 Multiple RESOLVED FIXED Medium normal 4.99 1 clemens.lang richard.purdie alex.kanavin JPEWhacker mikko.rapeli randy.macleod ross.burton samuli.piippo --- --- Don't know oldest_to_newest 48608 0 2397 clemens.lang 2015-02-06 13:57:35 +0000 Created attachment 2397 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. 60577 1 richard.purdie 2016-03-31 09:19:06 +0000 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... 83893 2 alex.kanavin 2019-05-23 12:39:47 +0000 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. 90996 3 randy.macleod 2021-07-22 15:22:36 +0000 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. 91411 4 JPEWhacker 2021-09-15 15:11:33 +0000 I believe this may have been fixed by https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=87c9d29 91461 5 richard.purdie 2021-09-16 15:44:14 +0000 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. 91993 6 richard.purdie 2021-11-12 17:32:58 +0000 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. 92009 7 richard.purdie 2021-11-15 13:19:05 +0000 http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=0562ab65936a11217cad570d4d633a246e20d3c6 92014 8 samuli.piippo 2021-11-16 15:12:38 +0000 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? 2397 2015-02-06 13:57:35 +0000 2015-02-06 13:57:35 +0000 Patch to change packaging of eglibc-utils -> libc-utils, triggering this bug if a packagegroup uses ${LIBC_DEPENDENCIES} 0001-eglibc-Package-ldconfig-in-eglibc-bin.patch text/plain 3499 clemens.lang ZGlmZiAtLWdpdCBhL21ldGEvcmVjaXBlcy1jb3JlL2VnbGliYy9lZ2xpYmMtcGFja2FnZS5pbmMg Yi9tZXRhL3JlY2lwZXMtY29yZS9lZ2xpYmMvZWdsaWJjLXBhY2thZ2UuaW5jCmluZGV4IDY3MjE4 MTkuLjdjZTYzNjkgMTAwNjQ0Ci0tLSBhL21ldGEvcmVjaXBlcy1jb3JlL2VnbGliYy9lZ2xpYmMt cGFja2FnZS5pbmMKKysrIGIvbWV0YS9yZWNpcGVzLWNvcmUvZWdsaWJjL2VnbGliYy1wYWNrYWdl LmluYwpAQCAtMTcsNyArMTcsNyBAQCBweXRob24gX19hbm9ueW1vdXMgKCkgewogIyBTZXQgdGhp cyB0byB6ZXJvIGlmIHlvdSBkb24ndCB3YW50IGxkY29uZmlnIGluIHRoZSBvdXRwdXQgcGFja2Fn ZQogVVNFX0xEQ09ORklHID89ICIxIgogCi1QQUNLQUdFUyA9ICIke1BOfS1kYmcgY2F0Y2hzZWd2 IHNsbiBuc2NkIGxkZCAke1BOfS11dGlscyBlZ2xpYmMtdGhyZWFkLWRiICR7UE59LXBpYyBsaWJj aWRuIGxpYm1lbXVzYWdlIGxpYnNlZ2ZhdWx0ICR7UE59LXBjcHJvZmlsZSBsaWJzb3RydXNzICR7 UE59IGVnbGliYy1leHRyYS1uc3MgJHtQTn0tZGV2ICR7UE59LXN0YXRpY2RldiAke1BOfS1kb2Mi CitQQUNLQUdFUyA9ICIke1BOfS1kYmcgJHtAYmFzZV9jb25kaXRpb25hbCgnVVNFX0xEQ09ORklH JywgJzEnLCAnJHtQTn0tYmluJywgJycsIGQpfSBjYXRjaHNlZ3Ygc2xuIG5zY2QgbGRkICR7UE59 LXV0aWxzIGVnbGliYy10aHJlYWQtZGIgJHtQTn0tcGljIGxpYmNpZG4gbGlibWVtdXNhZ2UgbGli c2VnZmF1bHQgJHtQTn0tcGNwcm9maWxlIGxpYnNvdHJ1c3MgJHtQTn0gZWdsaWJjLWV4dHJhLW5z cyAke1BOfS1kZXYgJHtQTn0tc3RhdGljZGV2ICR7UE59LWRvYyIKIAogIyBUaGUgbGQuc28gaW4g dGhpcyBlZ2xpYmMgc3VwcG9ydHMgdGhlIEdOVV9IQVNICiBSUFJPVklERVNfJHtQTn0gPSAiZ2xp YmMgcnRsZChHTlVfSEFTSCkiCkBAIC0yNSw2ICsyNSw3IEBAIFJQUk9WSURFU18ke1BOfS11dGls cyA9ICJnbGliYy11dGlscyIKIFJQUk9WSURFU18ke1BOfS1tdHJhY2UgPSAiZ2xpYmMtbXRyYWNl IGxpYmMtbXRyYWNlIgogUlBST1ZJREVTXyR7UE59LXBpYyA9ICJnbGliYy1waWMiCiBSUFJPVklE RVNfJHtQTn0tZGV2ID0gImdsaWJjLWRldiBsaWJjNi1kZXYgdmlydHVhbC1saWJjLWRldiIKK1JQ Uk9WSURFU18ke1BOfS1iaW4gPSAiZ2xpYmMtYmluIGxpYmM2LWJpbiB2aXJ0dWFsLWxpYmMtYmlu IgogUlBST1ZJREVTXyR7UE59LXN0YXRpY2RldiA9ICJnbGliYy1zdGF0aWNkZXYiCiBSUFJPVklE RVNfJHtQTn0tZG9jID0gImdsaWJjLWRvYyIKIFJQUk9WSURFU19lZ2xpYmMtZXh0cmEtbnNzID0g ImdsaWJjLWV4dHJhLW5zcyIKQEAgLTMzLDcgKzM0LDEwIEBAIFJQUk9WSURFU18ke1BOfS1wY3By b2ZpbGUgPSAiZ2xpYmMtcGNwcm9maWxlIgogUlBST1ZJREVTXyR7UE59LWRiZyA9ICJnbGliYy1k YmciCiBsaWJjX2Jhc2VsaWJzID0gIiR7YmFzZV9saWJkaXJ9L2xpYmNyeXB0Ki5zby4qICR7YmFz ZV9saWJkaXJ9L2xpYmNyeXB0LSouc28gJHtiYXNlX2xpYmRpcn0vbGliYy5zby4qICR7YmFzZV9s aWJkaXJ9L2xpYmMtKi5zbyAke2Jhc2VfbGliZGlyfS9saWJtKi5zby4qICR7YmFzZV9saWJkaXJ9 L2xpYm0tKi5zbyAke2Jhc2VfbGliZGlyfS9sZCouc28uKiAke2Jhc2VfbGliZGlyfS9sZC0qLnNv ICR7YmFzZV9saWJkaXJ9L2xpYnB0aHJlYWQqLnNvLiogJHtiYXNlX2xpYmRpcn0vbGlicHRocmVh ZC0qLnNvICR7YmFzZV9saWJkaXJ9L2xpYnJlc29sdiouc28uKiAke2Jhc2VfbGliZGlyfS9saWJy ZXNvbHYtKi5zbyAke2Jhc2VfbGliZGlyfS9saWJydCouc28uKiAke2Jhc2VfbGliZGlyfS9saWJy dC0qLnNvICR7YmFzZV9saWJkaXJ9L2xpYnV0aWwqLnNvLiogJHtiYXNlX2xpYmRpcn0vbGlidXRp bC0qLnNvICR7YmFzZV9saWJkaXJ9L2xpYm5zbCouc28uKiAke2Jhc2VfbGliZGlyfS9saWJuc2wt Ki5zbyAke2Jhc2VfbGliZGlyfS9saWJuc3NfZmlsZXMqLnNvLiogJHtiYXNlX2xpYmRpcn0vbGli bnNzX2ZpbGVzLSouc28gJHtiYXNlX2xpYmRpcn0vbGlibnNzX2NvbXBhdCouc28uKiAke2Jhc2Vf bGliZGlyfS9saWJuc3NfY29tcGF0LSouc28gJHtiYXNlX2xpYmRpcn0vbGlibnNzX2Rucyouc28u KiAke2Jhc2VfbGliZGlyfS9saWJuc3NfZG5zLSouc28gJHtiYXNlX2xpYmRpcn0vbGliZGwqLnNv LiogJHtiYXNlX2xpYmRpcn0vbGliZGwtKi5zbyAke2Jhc2VfbGliZGlyfS9saWJhbmwqLnNvLiog JHtiYXNlX2xpYmRpcn0vbGliYW5sLSouc28gJHtiYXNlX2xpYmRpcn0vbGliQnJva2VuTG9jYWxl Ki5zby4qICR7YmFzZV9saWJkaXJ9L2xpYkJyb2tlbkxvY2FsZS0qLnNvIgogCi1GSUxFU18ke1BO fSA9ICIke2xpYmNfYmFzZWxpYnN9ICR7bGliZXhlY2Rpcn0vKiAke0BiYXNlX2NvbmRpdGlvbmFs KCdVU0VfTERDT05GSUcnLCAnMScsICcke2Jhc2Vfc2JpbmRpcn0vbGRjb25maWcgJHtzeXNjb25m ZGlyfS9sZC5zby5jb25mJywgJycsIGQpfSIKK0ZJTEVTXyR7UE59ID0gIiR7bGliY19iYXNlbGli c30gJHtsaWJleGVjZGlyfS8qIgorTElDRU5TRV8ke1BOfSA9ICJMR1BMdjIuMSIKK0ZJTEVTXyR7 UE59LWJpbiA9ICIke0BiYXNlX2NvbmRpdGlvbmFsKCdVU0VfTERDT05GSUcnLCAnMScsICcke2Jh c2Vfc2JpbmRpcn0vbGRjb25maWcgJHtzeXNjb25mZGlyfS9sZC5zby5jb25mJywgJycsIGQpfSIK K0xJQ0VOU0VfJHtQTn0tYmluID0gIkdQTHYyKyIKIEZJTEVTX2xkZCA9ICIke2JpbmRpcn0vbGRk IgogRklMRVNfbGlic2VnZmF1bHQgPSAiJHtiYXNlX2xpYmRpcn0vbGliU2VnRmF1bHQqIgogRklM RVNfbGliY2lkbiA9ICIke2Jhc2VfbGliZGlyfS9saWJjaWRuLSouc28gJHtiYXNlX2xpYmRpcn0v bGliY2lkbi5zby4qIgpAQCAtNTYsNiArNjAsOCBAQCBGSUxFU19lZ2xpYmMtdGhyZWFkLWRiID0g IiR7YmFzZV9saWJkaXJ9L2xpYnRocmVhZF9kYi5zby4qICR7YmFzZV9saWJkaXJ9L2xpYnRocgog UlBST1ZJREVTXyR7UE59LWRldiArPSAibGliYy1kZXYiCiBSUFJPVklERVNfJHtQTn0tc3RhdGlj ZGV2ICs9ICJsaWJjLXN0YXRpY2RldiIKIAorU1VNTUFSWV8ke1BOfS1iaW4gPSAibGRjb25maWcg YW5kIGxkLnNvLmNvbmYiCitERVNDUklQVElPTl8ke1BOfS1iaW4gPSAiVG9vbCB0byBjb25maWd1 cmUgYW5kIHVwZGF0ZSB0aGUgZHluYW1pYyBsaW5rZXIgYW5kIGxvYWRlciBjYWNoZSBhbmQgaXRz IGNvbmZpZ3VyYXRpb24gZmlsZS4iCiBTVU1NQVJZX3NsbiA9ICJUaGUgc3RhdGljIGxuIgogREVT Q1JJUFRJT05fc2xuID0gIlNpbWlsYXIgdG8gdGhlICdsbicgdXRpbGl0eSwgYnV0IHN0YXRpY2Fs bHkgbGlua2VkLiAgc2xuIGlzIHVzZWZ1bCB0byBtYWtlIHN5bWJvbGljIGxpbmtzIHRvIGR5bmFt aWMgbGlicmFyaWVzIGlmIHRoZSBkeW5hbWljIGxpbmtpbmcgc3lzdGVtLCBmb3Igc29tZSByZWFz b24sIGlzIG5vdCBmdW5jdGlvbmFsLiIKIFNVTU1BUllfbnNjZCA9ICJOYW1lIHNlcnZpY2UgY2Fj aGUgZGFlbW9uIgotLSAKMi4xLjAKCg==