addon type defitions scaling poorly

[hsitter]

Addons extend other components. When the addon is an extension of a generic addon framework, this doesn't scale though.

Case in point the documentation currently suggest the following example for the extends tag

For example, if there is a plugin "kipi" which extens the application "Gwenview", [...]

which highlights the very problem with scaling.
kipi plugins are in fact addons for libkipi which is a generic plugin framework for picture manipulation used by any number of applications. Having the addons reverse-define the applications they add into does not scale for these generic frameworks. You'd have to list all possible applications for each plugin built on the framework. And on top of that the applications themselves may build without libkipi support so distro A may have kipi support in Gwenview while distro B does not, the plugin does not know that.

To deal with this properly I think a bunch of additions need to be made to link a generic plugin and an application without the two knowing about each other:

• There needs to be a library component type
• org.kde.libkipi defines itself through as a library component
• com.github.apachelogger.libkipi.blur is an addon tha then extends org.kde.libkipi
• org.kde.gwenview declares <uses>org.kde.libkipi</uses>

With this data we'd then be able to build a graph linking org.kde.gwenview to com.github.apachelogger.libkipi.blur without having the two know about each other.

[aleixpol]

Bump?

[ximion]

Hey :-)
So, first of all: I acknowledge the problem - this is something I have thought about already, but I haven't found a solution for this yet. Implementing something like you propose will add quite a lot of complexity, and - in a way - touches the question again on whether AppStream should define dependencies of software, and if so, how.

So far, I ignored both issues, because at the moment, AppStream is a really simple, straightforward to implement format. If we add additional logic like "X uses Y therefore inherits properties A and B from it", we'll add quite a bit of complexity.
And if we add that, we might as well go for the complete solution and add an easy way to define dependencies on other AppStream components and system facilities (like D-Bus interfaces or hardware) to the specification.
I am very unsure about this. I know @hughsie added something to define hardware requirements to his flavor of AppStream though.

In any case, on this issue, I'd say: Maybe we can fix it.
For the case of distros optionally compiling in Kipi, even your proposal won't help though - for that, I really think tools should hard-depend on the framework, unless there is a really strong reason to keep the dependency optional.