It is installing some IMHO crazily minimal python for an SDK, which in turn renders it unusable when the SDK is being used with third-party python software, e.g. using standard modules like json. Please ship a "full-fledged" SDK (i.e. standard python included), or just remove it completely. I do not think most of the users need a broken python to work with. It is worse than having nothing IMHO.
What specific SDK are you referring to? One downloaded from yoctoproject.org, or one you built yourself?
I am trying to generate an SDK for "stock" images, i.e. core-image-minimal at the moment. I think this issue is relatively complex: 1) There is no "catch-all" python enabler for the SDK. I do not want to fine-tune since I do not care about space in the SDK on the host. I would like to have such an enabler option for convenience if it is not shipped like that by default. 2) The documentation could mention that enabler, or if it is not added, we could at least have an example how to solve this for today. 3) Perhaps, the most important consideration is to whether change the default deployment. It does not seem to make much sense to ship a truncated python. It is probably not useful for anyone. a) therefore there should be none shipped, so that the SDK works for the user because the system-wide python installation is picked up. Hopefully, this would be allowed then by the SDK. b) a standard python is deployed by default, and someone would like to discard that, there would be option to cut that off.
So your image (in my case, core-image-minimal) contains libglib-2.0. A SDK contains all relevant -dev and -dbg packages, so libglib-2.0-dev is installed. -dev packages magically gain recommends at build time for the -dev form of every runtime dependency that every binary package has. This is usually the right thing to do: pango-dev magically depends on libglib-dev as it depends on libglib. *But* glib-2.0-ptest depends on Python and numerous glibc encodings, so the dependency list in libglib-2.0-dev is larger than expected: Package: libglib-2.0-dev Version: 1:2.40.0-r0.13 Depends: libglib-2.0-0 (= 1:2.40.0-r0.13) Recommends: python-pygobject-dev, libz-dev, libffi-dev, tzdata-posix-dev, tzdata-americas-dev, gnome-desktop-testing-dev, glibc-gconv-cp1255-dev, tzdata-asia-dev, python-dbus-dev, glibc-charmap-utf-8-dev, glibc-charmap-invariant-dev, glibc-gconv-euc-jp-dev, tzdata-dev, glibc-gconv-utf-7-dev, tzdata-europe-dev, libc6-dev, glibc-gconv-iso8859-15-dev, glibc-gconv-utf-32-dev, glibc-localedata-translit-cjk-variants-dev, dbus-dev, dbus-lib-dev, glibc-gconv-utf-16-dev, glibc-charmap-cp1255-dev, glibc-gconv-iso8859-1-dev, shared-mime-info-dev Not sure how best to solve this right now. The ptest packages are fairly special as they tend to have increased dependencies so maybe they should be filtered out when adding these automatic recommendations?
Okay slight confusion - the SDK has two python's, one in the host and one in the target. This chasing applies to the target version but that isn't executed. The host sysroot also has another python, where does *that* come from? More chasing tomorrow.
Thank you for your swift response. Yeah, this fine-tuning might be reasonable for the target (although if the space matters that much, why python and not C, busybox ash, etc, in the first place?), but for the host where we have powerful machines, a standard python enabler and/or disabler are nice to have IMHO. Just in case you are wondering why I am using python on the host: I am generating some boiler plate code for a C project, because it is handier in python than ugly C macros IMHO.
On the host side, what is happening is that gdb has python enabled. This is therefore pulling in the python dependencies it needs and adding these to the SDK when the SDK includes gdb. The two fixes that spring to mind are therefore disabling python support in gdb, or adding python and its modules to the "assume provided" list of the SDK (like bash is currently). We may have some problems dynamically listing all python modules in that list though.
Resolved in oe-core e36ff98a7a4da478bb886f61005cd72a0b5a9c0e.
Thanks!