path: root/meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb
Commit message (Collapse)AuthorAgeFilesLines
* buildtools-tarball: fix perl being included when building with ipkPaul Eggleton2016-04-181-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to some logic within opkg, a package with the name matching a dependency will always win over a package with that name in RPROVIDES - even if there is an RCONFLICTS (which is silently ignored), higher feed priority and version. The end result is that buildtools gets perl installed instead of the nativesdk-buildtools-perl-dummy package and that perl (with missing dependencies) gets used in preference to the host one, which is precisely what we were trying to avoid. This is almost certainly a bug in opkg, especially as the other package's dependencies aren't properly installed under these circumstances either. However, specifying RREPLACES works around this, and with no apparent side-effects is probably the safest solution for now. At the same time I noticed that in prepending to SDK_PACKAGE_ARCHS we were actually ending up with a low priority for the dummy package feed rather than a high one, so change to append it instead. This has no effect on the packages that get installed at the moment, but should be done in case the package manager behaviour changes to factor in the feed priority in future. Fixes [YOCTO #9469]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* nativesdk-buildtools-perl-dummy.bb: Fix variable expansion in python codeAníbal Limón2016-02-111-2/+2
| | | | | | | | | | | Since python expansion of bb data variables is disable in order to provide a standard interface usage for expand variables this variables aren't expanded now so change to call d.expand('${VAR}'). This API expansion change was causing to install perl in nativesdk. Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* nativesdk-buildtools-perl-dummy: Bump PRRichard Purdie2015-12-181-0/+2
| | | | | | | | Recent changes to this recipe caused automated PR increments to break, regressing package feeds. The only way to recover is to bump PR, so do this centrally to fix anyone affected. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* nativesdk-buildtools-perl-dummy: properly set PACKAGE_ARCHPaul Eggleton2015-12-111-2/+0
| | | | | | | | | | | | | Turns out I did a silly thing in OE-Core revision 9b1831cf4a2940dca1d23f14dff460ff5a50a520 and forgot to remove the explicit setting of PACKAGE_ARCH outside of the anonymous python function; the original bug was apparently fixed but the functionality of allarch.bbclass was being disabled because it was able to see that PACKAGE_ARCH was not set to "all" - which was what I was trying to ensure. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* nativesdk-buildtools-perl-dummy: fix rebuilding when SDKMACHINE changesPaul Eggleton2015-12-011-2/+9
| | | | | | | | | | | | | | | | This recipe produces an empty dummy package (in order to satisfy dependencies on perl so we don't have perl within buildtools-tarball). Because we were inheriting nativesdk here the recipe was being rebuilt, but having forced PACKAGE_ARCH to a particular value the packages for each architecture were stepping on eachother. Since the packages are empty they can in fact be allarch (even though they won't actually go into the "all" package feed). It turns out that nheriting nativesdk wasn't actually necessary either, so drop that. Fixes [YOCTO #8509]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* buildtools-tarball: restore missing git toolsPaul Eggleton2014-12-191-0/+19
Since the split out of git-perltools, some git tools (such as "git am", "git send-email" and "git-submodule") have no longer been part of the buildtools. We need these, so add them back in. However, adding git-perltools to buildtools triggers perl itself being brought into buildtools as well, and we don't want that; but we also don't want to have to hack the git recipe or indeed anything else that starts depending on perl. Thus, add a dummy package which gets installed in its place, in a separate package architecture that is only enabled for buildtools to ensure it doesn't start appearing in place of nativesdk-perl anywhere else. Fixes [YOCTO #7033]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>