Packaging rules for an arch-independent GEdit plugin
Howdy all,
I am attempting to package a GEdit plugin [0], written in
architecture-independent Python.
The build dependencies are all architecture-independent, and as far as I
can tell the build and installation process is architecture-independent.
The upstream install script consists essentially of copying some files
to ‘/usr/lib/gedit/plugins/’.
When I do this in the Debian package, though, the resulting plug-in
fails to load because it can't find ‘gi.repository.Gedit’.
File "/usr/lib/gedit/plugins/editorconfig_gedit3.py", line 1, in
<module>
from editorconfig_plugin.gedit3 import *
File "/usr/lib/gedit/plugins/editorconfig_plugin/gedit3.py", line
26, in <module>
from gi.repository import GObject, Gedit
File "/usr/lib/python3/dist-packages/gi/importer.py", line 127, in
find_module
'introspection typelib not found' % namespace)
ImportError: cannot import name Gedit, introspection typelib not
found
Every other GEdit plug-in packaged in Debian, even the pure Python ones,
appears to be installed to an architecture-specific location, not
‘/usr/lib/gedit/plugins/’. Why the difference? Is this incorrect?
An example of this is the GEdit plugin from the ‘rabbitvcs’ source
package. Apparently it relies on ‘dh_install’, to simply install the
plugin files directly to ‘/usr/lib/gedit/plugins/’.
How should a third-party GEdit plugin, architecture-independent Python
code, be packaged for Debian so that it will work correctly in GEdit?
What do I need to do in the packaging to convince Gedit to see the
files? What Debhelper (or other) tools are there in Debian to help make
this simple?
[0] ‘editorconfig-gedit’ <URL:bugs.debian.org/889696>.
--
\ “I do not believe in immortality of the individual, and I |
`\ consider ethics to be an exclusively human concern with no |
_o__) superhuman authority behind it.” —Albert Einstein, letter, 1953 |
Ben Finney
Reply to: