GNOME Bugzilla – Bug 554535
Gedit should load plugins also from /usr/share/gedit
Last modified: 2020-11-24 10:18:56 UTC
Hi. I'm packaging for fedora linux a pure python plugin (LatexPlugin) for gedit. Gedit loads its plugins from /usr/lib/gedit-2/plugins. In multilib systems this translate to two different libdirs depending on the architecture (either 32 or 64 bits) and thus two different compiled packages. But this is very inconvenient, because a pure python extension is architecture-independent and a single package could be provided. To allow this behaviour, gedit should load architecture-independent plugins from architecture-independent directories. A reasonable directory is /usr/share/gedit-2/plugins/
Chatting with paolo we endup with the next: 1) we already use share for other non script files 2) share is not the proper place for code Sorry for the late response but I'm marking this as WONTFIX.
Please reopen as per https://bugzilla.redhat.com/show_bug.cgi?id=737399
Reopening on libpeas. Let's see what they think.
What's wrong with just using peas_engine_add_search_path() to add the directory in /usr/share ?
(In reply to comment #0) > Hi. I'm packaging for fedora linux a pure python plugin (LatexPlugin) for > gedit. Gedit loads its plugins from /usr/lib/gedit-2/plugins. In multilib > systems this translate to two different libdirs depending on the architecture > (either 32 or 64 bits) and thus two different compiled packages. > But this is very inconvenient, because a pure python extension is > architecture-independent and a single package could be provided. To allow this > behaviour, gedit should load architecture-independent plugins from > architecture-independent directories. A reasonable directory is > /usr/share/gedit-2/plugins/ This is likely not the right place for this bug report, but it is the best I could find. gedit has at least 2 major problems in Fedora 19: 1. LaTeX mode has broken. I tried a number of things to try to get it working, but failed. It worked correctly before upgrade from Fedora 18 to 19. 2. When attempting to install additional packages I found that some (such as LaTeX plugins) depend on the Fedora texlive packages, of which there are many hundreds. I use the texlive from CTAN and therefore CANNOT install the fedora texlive. 3. I tried to make gedit 3.9.3, but this fails reporting checking for GEDIT... no 4. I compiled and installed gedit 3.8.3 and it fails the same way the Fedora 10 release does. I came to depend on gedit, which has many very good features, but may now have to abandon it due to its lack of compatibility with Fedora 19.
We need this feature also for rabbitvcs plugin. Currently, it's possible only with /usr/lib[64]/gedit/plugins/rabbitvcs-plugin.py that prevents from building it as a noarch package.
As it says in upstream documentation: Both of these files need to be placed in either the system-wide plugins directory /usr/lib/gedit/plugins/, or in the user plugins directory, which may need to be created, ~/.local/share/gedit/plugins/. https://wiki.gnome.org/Apps/Gedit/PythonPluginHowTo It's confusing to use share for user specific plugins but globally lib folder that is not arch independent if you have 64 bits.
Mass-closing of all gedit-plugins bugzilla tickets. Special "code" to find again all those gedit-plugins bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.