RFC: Creation of a new KDE SC module [kdeplugins]
George Kiagiadakis
kiagiadakis.george at gmail.com
Sun Oct 10 19:34:40 BST 2010
On Sun, Oct 10, 2010 at 5:11 PM, Dawit A <adawit at kde.org> wrote:
> On Sun, Oct 10, 2010 at 3:40 AM, Sune Vuorela <nospam at vuorela.dk> wrote:
>> Currently konqueror-plugins are released in extrager, which is quite
>> okay.
>
> Then you completely missed the entire point of this discussion. It is
> "not quite okay" they are in extragear because it is a complete
> maintainence nightmare. Please read the discussion links I provided
> above. The plugins, at least as far as konqueror ones are concerned,
> need to be versioned the same way Konqueror does. However, the plugins
> themselves are "optional" (not needed to run Konqueror) and hence are
> located outside of Konqueror's source tree.
>
> The idea behind creating this new package/module just for plugins is
> to ensure that they are part of the normal branching and tagging cycle
> such that we do not have to worry about which version of the plugins
> goes with which version of the application. kdeplugins is intended to
> be a place to add all plugins that benefit from this.
And why not just put the plugins in kdebase together with konqueror
and just make their directory optional with
macro_add_optional_subdirectory() in CMakeLists.txt? I don't see why
they need to be separated. They can be together and still be optional.
Packagers will take care of having them in a separate optional
package. If you want them to be released together with konqueror, then
the best place is there. Having a kdeplugins module with random
plugins for various applications doesn't make much sense to me. And as
far as I understand, there are no other plugins to be put in this new
module, it's just for the konq plugins, isn't it? All other
applications ship plugins together with the application... see kate,
ktorrent, kdevelop, kopete, etc...
Just my 2 cents...
Regards,
George
More information about the kde-core-devel
mailing list