[OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain

[Paul Eggleton]

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 <marex at denx.de> 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