| Summary: | Different PACKAGE_ARCH in recipe only for some package or MACHINE causes missing ipk files in deploy | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Martin Jansa <Martin.Jansa> |
| Component: | configuration | Assignee: | Richard Purdie <richard.purdie> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | sgw |
| Version: | 1.4 | ||
| Target Milestone: | 1.4 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Martin Jansa
2012-11-06 06:12:22 UTC
For 1), I'm not sure we can support this type of syntax. When you think about it, repeatedly overwriting some "all" arch package is a bad thing and can lead to races like you describe. The problem has always been there, we're just specifically identifying it now. For 2), the key problem is that udev-extraconf is an allarch recipe. If you do this on a normal recipe, things will work but you can't "uninherit" allarch which means peices still apply. In both cases, I therefore thing we should not support these particular specialist usecases and fine alternatives. (In reply to comment #1) > For 1), I'm not sure we can support this type of syntax. When you think > about it, repeatedly overwriting some "all" arch package is a bad thing and > can lead to races like you describe. The problem has always been there, > we're just specifically identifying it now. So should I remove just PACKAGE_ARCH_update-alternatives-cworth = "all" or do we want separate update-alternatives-cworth recipes which can be allarch, like we had before? > For 2), the key problem is that udev-extraconf is an allarch recipe. If you > do this on a normal recipe, things will work but you can't "uninherit" > allarch which means peices still apply. So can I remove allarch from udev-extraconf recipe to resolve this? Or should I add another recipe which is MACHINE_ARCH by default (e.g. to provide machine specific mount.blacklist)? > In both cases, I therefore thing we should not support these particular > specialist usecases and fine alternatives. Patches sent to ML http://lists.linuxtogo.org/pipermail/openembedded-core/2012-November/031806.html http://lists.linuxtogo.org/pipermail/openembedded-core/2012-November/031807.html For issue 1), http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=eaa7c3a37111e254217263a26306018aebd7953f was merged which fixes the issue. For issue 2), http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=668f7e36fe2c681a1b5c7604fe34960956448eec was merged as an alternative fix which also addresses other issues. |