update-alternatives: Fix for compatibility with multilib recipes

update-alternatives: Fix for compatibility with multilib recipes

[Richard Purdie]

The PN == BPN test was designed to exclude native/nativesdk but also unfortunately
excludes multilib unintentionally. This change fixes this and allows multilib images
with alternatives to funciton correctly.

[YOCTO #2214]

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
diff --git a/meta/classes/update-alternatives.bbclass b/meta/classes/update-alternatives.bbclass
index ae58344..7b0518d 100644
--- a/meta/classes/update-alternatives.bbclass
+++ b/meta/classes/update-alternatives.bbclass
@@ -69,15 +69,16 @@ done
 }
 
 update_alternatives_batch_doinstall() {
-if [ "${PN}" = "${BPN}" ] ; then
 	for link in ${ALTERNATIVE_LINKS}
 	do
 		mv ${D}${link} ${D}${link}.${PN}
 	done
-fi
 }
 
 def update_alternatives_after_parse(d):
+    if bb.data.inherits_class('native', d) or bb.data.inherits_class('nativesdk', d):
+        return
+
     if d.getVar('ALTERNATIVE_LINKS') != None:
         doinstall = d.getVar('do_install', 0)
         doinstall += d.getVar('update_alternatives_batch_doinstall', 0)

Re: update-alternatives: Fix for compatibility with multilib recipes

[Chris Larson]

On Sat, Apr 14, 2012 at 10:31 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>  def update_alternatives_after_parse(d):
> +    if bb.data.inherits_class('native', d) or bb.data.inherits_class('nativesdk', d):
> +        return
> +

Not an issue, but wanted to point out we have a utility function for
this sort of thing, for future reference. bb.utils.inherits(d,
'native', 'nativesdk'), iirc.
-- 
Christopher Larson