<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 2 December 2014 at 17:02, Mark Hatle <span dir="ltr">&lt;<a href="mailto:mark.hatle@windriver.com" target="_blank">mark.hatle@windriver.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":6s8" class="a3s" style="overflow:hidden">Personally I think using &quot;${exec_prefix}/libexec&quot; is incorrect.  This does not support a multilib configuration where you may have both a 64-bit and 32-bit version of the libexec program on the system.  (perhaps this isn&#39;t a real problem, but we ran into some conflicts in the past.)<br></div></blockquote><div><br></div><div>Are any of these conflicts actually a problem?  Can you give an example?  I know there&#39;s been several attempts to &quot;fix&quot; GConf multilib installation which were generally breaking GConf instead of fixing a test case...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":6s8" class="a3s" style="overflow:hidden">
So moving to the libdir, ensures that we are unique per multilib.. and the BPN ensures that we&#39;re unique per recipe.<div></div></div></blockquote></div><br>A libexecdir that isn&#39;t global is a problem because some packages want to run *other recipes* binaries, and they can&#39;t just do $libexecdir/some-binary.  </div><div class="gmail_extra"><br></div><div class="gmail_extra">Ross</div></div>