On Monday 01 December 2014 15:13:30 Richard Purdie wrote: > On Mon, 2014-12-01 at 15:05 +0000, Burton, Ross wrote: > > On 21 September 2014 at 17:02, Marek Vasut <[email protected]> wrote: > > -TOOLCHAIN_HOST_TASK ?= "nativesdk-packagegroup-sdk-host > > packagegroup-cross- > > canadian-${MACHINE}" > > +TOOLCHAIN_HOST_TASK ?= " \ > > + nativesdk-packagegroup-sdk-host \ > > + packagegroup-cross-canadian-${MACHINE} \ > > + nativesdk-python-modules > > > > 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. > > > > 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: > > > > 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. > > Agreed on smartpm, rpm is a bit of a different story due to where it > gets used in the packaging process. As the SDK and build systems > converge this gets a bit fuzzy :/.
I'm not entirely sure python-smartpm should have been added by default in the first place. I'd say having it there ought to be the choice of the person creating the SDK, just as with a lot of other tools one might want in the SDK. For most people I suspect it's superfluous. > > 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. > > > > Comments? > > Make nativesdk-python-core RRECOMMEND python-modules? This sounds like a reasonable option to me. The split as it is at the moment exists mainly for trimming the target; the SDK is perhaps less sensitive to size constraints. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
