Split plugins in separate packages (in Fedora)

Bug #591747 reported by Luca Invernizzi on 2010-06-09
20
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Getting Things GNOME!
Medium
Izidor Matušov

Bug Description

From bug 493269, by https://edge.launchpad.net/~bochecha
=====================================================

(Disclaimer: I co-maintain GTG in Fedora)

Just for the record, I think this is a packaging issue in Fedora.

I had seen the issue and was planning on fixing it properly in the package by:
1. splitting the plugins into a subpackage
2. making the gtg-plugins package require the necessary Python modules
3. making sure those modules are properly packaged in Fedora
4. eventually, if that's worth it, splitting each plugin in its own subpackage, each one requiring its own Python dependencies

Like I said, I wanted to do that when I would find the time, and obviously discuss that with upstream GTG (i.e. you). I don't have the time right now, but I just found this bug report, so I guess this is a rather good place to open this discussion.

So what do you think? Does splitting the plugins from the core GTG make sense from a packaging perspective? Does splitting each plugin in its own subpackage make sense?

What's your take on this?

PS: I didn't want to reopen the bug as it's a slightly parallel issue and it's relative to a downstream distributor, should this bug be reopen? Should I open a new one?

Related branches

Luca Invernizzi (invernizzi) wrote :

That's a complex question :). Here's my ideas:

1. splitting the plugins into a subpackage

2. making the gtg-plugins package require the necessary Python modules
3. making sure those modules are properly packaged in Fedora
If someone wants to have a single plugin, it has to install the whole package dependencies. The tomboy plugin, for example, does not require any additional module, but to have it you will need to install python-geoclue. I'm almost sure that in the necessary modules for the geolocalization plugin are not packaged in fedora (they aren't in ubuntu), and they're quite unstable.
IMHO, this is not a great solution, as it gives you additional work without great benefit for the users (well, they'll have the geolocalization plugin working :) ).

4. eventually, if that's worth it, splitting each plugin in its own subpackage, each one requiring its own Python dependencies.
This is better, but gives all the packages a lot of work. From the user standpoint, plugins will not be "advertised" as they are now, so they might miss them.

For the debian&co distributions, a good solution is providing apt:// links. The user just need to click on that to install the required modules. Does fedora have something simiar? Otherwise, we could pop out a terminal with the yum (I believe) line to install the package. It's far less beautiful than apt:// links, but it would work.

GTG devs, what do you think?

ps: Thanks for packaging GTG!

Luca Falavigna (dktrkranz) wrote :

Speaking with my Debian/Ubuntu package maintainer hat on, I didn't pay too much attention to plugins required dependencies, say because it's clearly stated by gtg itself, say because some plugins are of little interest, and it's not worth the pain adding to Recommends full stack of required Python packages.

I must admit that it's not the preferred way to do this, because users expect gtg to work out of the box immediately, leaving apt/dpkg the task of installing dependencies, and this never happened since now. I can't blame users for reporting bugs, and "fixing" them by adding packages to Recommends falls into the first behaviour, which I want to avoid.

The best solution to me is having separate packages for plugins (a single package for mostly used ones, and a gtg-plugins-others for niche ones) on top of gtg sources, so we avoid of publishing two separate source tarballs. In Debian/Ubuntu this is easily doable, I don't know about Fedora.

Mathieu Bridon (bochecha) wrote :

I agree that only one subpackage is not ideal for the user regarding dependencies. However, one subpackage per plugin adds some churn in the repositories metadata for very few actual code (each plugin being a very simple piece of code).

Maybe a tradeoff could be found, like grouping together plugins that have similar dependencies, or that help achieve similar tasks, etc... I'll try to think about that.

About the apt:// url, we have something like that in Fedora too: the PackageKit API.

The good thing about it is that it is completely cross-distributions, and already adopted in several upstream Gnome projects:
 - double-click on a file for which you have no application able to handle it, Nautilus will ask PackageKit to present the user a list of applications that can be installed that would handle this mimetype
 - open a multimedia file for which no codec is installed, Gstreamer will ask PackageKit to present the user a list of packages containing the required codecs to play the file
 - open a document in Abiword, a web page in Epiphany (or just anything that tries to display "exotic" characters), Pango (I think it's Pango, I would have to verify that though) will ask PackageKit to present the user a list of available fonts that would be able to display those Chinese characters present in the file
 - plug a printer for which you don't have the drivers on your system, system-config-printer will ask PackageKit to present the user the possibility to install the proper driver
 - etc...

The downside is that not all distributions adopted it yet. But if it didn't stop Gstreamer, Nautilus, system-config-printer and more every 6 months, I can't see any reason it should stop GTG :)

Imagine the plugin dialog in GTG, with a nice "find more plugins" button that would launch the native package manager of the distribution through PackageKit and present the user the list of available plugins, and if the user desires, install them along with their dependencies. Did I mention it would work both on Gnome, KDE, and just any other desktop environment that has a PackageKit front-end?

And thanks to the PackageKit browser plugin, you could do the same on your website (again, just like the apt:// link, but cross-distributions).

What? You say Debian/Ubuntu won't adopt PackageKit for politico-technical reasons? Fear not, for the sessioninstaller they are developing aims to implement the PackageKit DBus API, so all applications using PackageKit will work the same with sessioninstaller.
    http://wiki.debian.org/SessionInstaller

That seems like the proper solution for GTG to advertise its plugins to me. ;)

PS: I didn't package GTG in Fedora, Yanko did. I only offered him my help to co-maintain it. Sorry to nitpick, I only wanted to not take credit for Yanko's work. :)

PPS: to my knowledge, there isn't any Windows backend for PackageKit ( yet? :P )

Mathieu Bridon (bochecha) wrote :

> The best solution to me is having separate packages for plugins (a single package for mostly used ones, and a gtg-plugins-others for niche ones) on top of gtg sources, so we avoid of publishing two separate source tarballs. In Debian/Ubuntu this is easily doable, I don't know about Fedora.

We can simply create subpackages from the same source tarball if necessary (which is what I was planning to do here).

In case someone is wondering, this is true for all RPM-based distributions.

On Wed, Jun 09, 2010 at 03:36:57PM -0000, Mathieu Bridon (bochecha) wrote:
> > The best solution to me is having separate packages for plugins (a
> single package for mostly used ones, and a gtg-plugins-others for niche
> ones) on top of gtg sources, so we avoid of publishing two separate
> source tarballs. In Debian/Ubuntu this is easily doable, I don't know
> about Fedora.

I agree. I think I'd suggest calling it gtg-plugins-extras rather than
-others as it seems to be more conventional.

Changed in gtg:
status: New → Confirmed
importance: Undecided → Medium
milestone: none → 0.3
Paul Natsuo Kishimoto (khaeru) wrote :

I use the tomboy-latex plugin. The version in the repos is out of date, so I run the latest version from the author. His install instructions recommend installing certain packages. What this example makes me realize, in the case of GTG, is:
 * If a plugin is going to be distributed by a package management system (e.g. in Ubuntu, via the repositories or a PPA), then the packaging can be used to satisfy the dependencies, OR
 * If a plugin is to be manually installed by the user, it is appropriate for the plugin author to provide some instructions ("Be sure to sudo apt-get install python-this python-that.")

Unless we can think of a third case, then this would allow getting rid of some parts of the GTG plugins code. GTG will still have to check that a plugin can be loaded, but it doesn't have to struggle to provide intelligible instructions to the user on which packages to install. Instead, plugin dependency failures can trigger either:
 * An apport bug submission with the relevant details (core plugins from gtg-plugins*) OR
 * A preformatted bug report to be sent to the plugin author (manually-installed plugins)

> gtg-plugins-extras
From the example of the texlive-* packages, it should be "extra" (not plural).

Lionel Dricot (ploum) wrote :

Is there something that should be done in the upstream project ?

Mathieu Bridon (bochecha) wrote :

> Is there something that should be done in the upstream project ?

Well, there was this, buried in the middle of the discussion:

> Imagine the plugin dialog in GTG, with a nice "find more plugins" button
> that would launch the native package manager of the distribution
> through PackageKit and present the user the list of available plugins,
> and if the user desires, install them along with their dependencies. Did
> I mention it would work both on Gnome, KDE, and just any other desktop
> environment that has a PackageKit front-end?

However, I don't co-maintain GTG any more in Fedora (I stopped using it a while ago), so I'll remove myself from this bug.

Thanks.

Izidor Matušov (izidor) on 2012-08-11
Changed in gtg:
assignee: nobody → Izidor Matušov (izidor)
status: Confirmed → In Progress

Is there any chance to fix this for 0.3? Do we have some kind of solution?

Luca Falavigna (dktrkranz) wrote :

I think documenting plugin dependencies in README would be enough, split plugins should really be done by distributions.

Izidor Matušov (izidor) on 2012-11-02
Changed in gtg:
status: In Progress → Fix Committed
Changed in gtg:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers