It seems that since version 2.28 , dev-libs/glib has started depending on python. Is there a chance that this can be made optional by ect. a USE flag? It's a bit of a problem, since I build packages into a folder, and then syncs that to my router, which has very little diskspace, so having to install python is annoying, since I don't need python on that machine. So, would it be possible to remove the requirement of python, or make it optional?
python was needed at build time and for tests at some point but it seems a couple of patches have been applied to remove that dependency. However since the ebuild still inherits the python eclass it still pulls python dependency in. Needs to be checked.
I believe that Gentoo's glib-2.28 doesn't actually need python for anything; the dependency is an ebuild artefact. glib-2.30 (coming in September) will need python both at buildtime and runtime for the new gdbus-codegen tool. Of course, if you aren't doing software development on your router, the library part of glib will continue to run fine without python installed. (Note to self: perhaps gdbus-codegen should be split off into a separate ebuild? Need to think about it...) For now, you can work around this issue by adding dev-lang/python-2.7.1 to your router's /etc/portage/package.provided file (assuming you are, somehow, using portage on a machine that doesn't have python installed). Note that this workaround is not ideal because it will hide any *real* python dependencies that could arise in the future with another package.
Grepping at sources looks like it could be needed for some tests, but tests should be skipped if dbus-python is missing now. I also see this references: glib/Makefile.in:@OS_UNIX_TRUE@ -e '1,1s|#! /usr/bin/env python\([0-9]\+\(\.[0-9]\+\)\?\)\?|#!${PYTHON}|' \ glib/Makefile.am: -e '1,1s|#! /usr/bin/env python\([0-9]\+\(\.[0-9]\+\)\?\)\?|#!${PYTHON}|' \ glib/gen-iswide-table.py:#!/usr/bin/python glib/update-pcre/update.sh:python $IN/make_utt.py
(In reply to comment #2) > (Note to self: perhaps gdbus-codegen should be split off into a separate > ebuild? Need to think about it...) Fixed in gnome-next; gdbus-codegen is now a separate package. As a result, when glib-2.30 comes to portage (in September, most likely), it will not use python.eclass and will not have a runtime dependency on python.
Could this be backported to 2.28 ebuild ?
Wouldn't it be better to add a configure switch and a use flag to ship, or not, the gdbus-codegen tool and put it upstream ?
(In reply to comment #5) > Could this be backported to 2.28 ebuild ? In 2.28, the situation is even simpler: it doesn't have gdbus-codegen and only uses python for tests, so instead of inheriting python, we can do "sed -e 's:#!/usr/bin/env python:!/usr/bin/env python2:' -i gio/tests/gdbus-testserver.py". (In reply to comment #6) > Wouldn't it be better to add a configure switch and a use flag to ship, or not, > the gdbus-codegen tool and put it upstream ? No. The user experience for Gentoo would be worse. If gdbus-codegen were a USE flag, users would be forced to recompile all of glib (5 minutes on a dual-core machine) if they wanted to install something that depended on the tool; by contrast, emerging a separate gdbus-codegen package is almost instantaneous, since it can avoid glib's build system entirely and simply copies a few .py files from the glib tarball. And upstream would not want such a switch for the same reason that they would not want a switch to build just the headers or just the libraries, even though most distros (Debian, Fedora, etc.) split glib into separate "glib-devel" and "libglib" packages.
(In reply to comment #7) > 's:#!/usr/bin/env python:!/usr/bin/env python2:' Typo, should be 's:#!/usr/bin/env python:#!/usr/bin/env python2:'
(In reply to comment #7) > (In reply to comment #5) > > Could this be backported to 2.28 ebuild ? > > In 2.28, the situation is even simpler: it doesn't have gdbus-codegen and only > uses python for tests, so instead of inheriting python, we can do "sed -e > 's:#!/usr/bin/env python:!/usr/bin/env python2:' -i > gio/tests/gdbus-testserver.py". > But, I guess, python would still be needed at build time for that test, no? (but it would be only needed with USE="test")
Any news on this? It would be really nice to not have python as a dependency :)
(In reply to comment #10) > Any news on this? > > It would be really nice to not have python as a dependency :) Pythonless glib-2.29.something should be coming to portage soon™. Package-masked initially, of course.
This won't be backported to 2.28, fixed in 2.30 (already in the tree)
*** Bug 394941 has been marked as a duplicate of this bug. ***
