<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 21 September 2014 at 17:02, Marek Vasut <span dir="ltr"><<a href="mailto:marex@denx.de" target="_blank">marex@denx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="overflow:hidden">-TOOLCHAIN_HOST_TASK ?= "nativesdk-packagegroup-sdk-host packagegroup-cross-<br>
canadian-${MACHINE}"<br>
+TOOLCHAIN_HOST_TASK ?= " \<br>
+ nativesdk-packagegroup-sdk-host \<br>
+ packagegroup-cross-canadian-${MACHINE} \<br>
+ nativesdk-python-modules </div></blockquote></div><br>Thanks to Laszlo for pinging this. We fixed a similar problem in the buildtools tarball by pulling in python-modules but the situation was different there - the buildtools tarball always contained some of Python so it's logical to make it pull in all of python.</div><div class="gmail_extra"><br></div><div class="gmail_extra">It's nativesdk-packagegroup-sdk-host that's pulling in parts of Python via it's dependency on smartpm. This makes me think we need two changes here:</div><div class="gmail_extra"><br></div><div class="gmail_extra">1) The toolchain should contain the packaging tools for the selected packaging format of the images, not just smartpm. So a SDK for a opkg-based image should be shipping opkg, not smartpm.</div><div class="gmail_extra"><br></div><div class="gmail_extra">2) Toolchains should either ship no Python or all Python, because dropping a partial Python into $PATH breaks user's expectations (the same argument that was used for the buildtools). Not sure how to do this though, maybe the construction should inspect the installed package list and if anything Python was installed, ensure python-modules is also installed.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Comments?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Ross</div></div>