1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.GTK.GN

  • Packaging rules for an arch-independent GEdit plugin

    From Ben Finney@21:1/5 to All on Thu Feb 8 09:00:01 2018
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeremy Bicha@21:1/5 to Ben Finney on Thu Feb 8 13:30:01 2018
    On Thu, Feb 8, 2018 at 2:09 AM, Ben Finney <bignose@debian.org> wrote:
    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/’.

    There are several gedit plugins installed to /usr/lib/gedit/plugins/.

    apt-file search tells me about gedit-developer-plugins,
    gedit-latex-plugin, gedit-source-code-browser-plugin, and
    supercollider-gedit in addition to rabbitvcs-gedit.

    Debian's gedit is supposed to support both the multi-arch and
    non-multiarch paths (/usr/lib/x86_64-linux-gnu/gedit/plugins and /usr/lib/gedit/plugins ).

    If you want someone to take a closer look, please point to your packaging.

    Thanks,
    Jeremy Bicha

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)