Summary: | >=dev-libs/glib-2.28 requires python | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bjarke Istrup Pedersen (RETIRED) <gurligebis> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | Marc-Antoine, polynomial-c |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Bjarke Istrup Pedersen (RETIRED)
2011-08-03 11:54:06 UTC
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. *** |