Python bindings for GObject
Pygobjects is an extension module for python that gives you access to
GLib's GObjects.
- Developed at GNOME:Factory
- Sources inherited from project openSUSE:Factory
-
8
derived packages
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout openSUSE:Factory:RISCV/python-gobject && cd $_ - Create Badge
Refresh
Refresh
Source Files
| Filename | Size | Changed |
|---|---|---|
| _service | 0000000716 716 Bytes | |
| pygobject-3.48.2.obscpio | 0002975756 2.84 MB | |
| pygobject.obsinfo | 0000000099 99 Bytes | |
| python-gobject.changes | 0000104864 102 KB | |
| python-gobject.spec | 0000008227 8.03 KB |
Latest Revision
Ana Guerrero (anag+factory)
accepted
request 1166245
from
Dominique Leuenberger (dimstar)
(revision 98)
- Update to version 3.48.2:
+ Fix support for fundamental (primitive) types, such as
Gst.Bitmask. (forwarded request 1166090 from dimstar)
Comments 11
What's up with the extra -Gdk package split? The changelog suggests that it's to prevent depending on various X11 related things, but overrides in PyGObject are only active if the respective typelib gets loaded and they don't add a dependency.
The deps is on an RPM level - having typelib(GtK) being pulled in means you get an X-stack for all cases.
(I'm not that familiar with the rpm/spec sytem)
What does pull in the gtk typelib?. PyGObject does not depend on gtk+, only its test suite those.
e.g. from /usr/lib64/python2.7/site-packages/gi/overrides/Gdk.py
require_version("GdkX11", Gdk._version) from gi.repository import GdkX11=> that gives a typelib(GdkX11) dependency
hence, not splitting Gdk.py into a sep sub-package makes the entire python[23]-gobject require GTK dependencies
and if you install a headless system (think also containers), you're happy to be able to avoid deps on pango, cairo. gtk, x11
If you don't use gdk this file never gets executed so it doesn't add a dependency.
RPM has to satisfy its dependencies at install time, not at runtime.
There is nothing to satisfy as there is no dependency.
anyway, just note that splitting things this way is not supported upstream and you get to keep the bug reports.
If upstream does not get the concept of rpm deps, I honestly do not care - packaging bugs are ours, and upstream would not care for them anyway. This split is understood by us distro maintainers and why know how to deal with it.
I guess I don't get it. It just seems like added complexity for no gain to me.
Looking at some pygobject apps: pitivi, lollypop, gramps, d-feet don't seem depend on it.