importing XML, CSS, Upload, Xdebug, Execute Script, Execute Browser etc. pp. plugins into Quanta

[Alexander Shaduri]

On Mon, 7 Jun 2010 16:13:50 +0200
Milian Wolff <mail at milianw.de> wrote:

> > Thank you both for your answers.
> > Just one quick question though: Would these plugins be distributed
> > as part of Quanta, or separately? That is, would I have to have Quanta
> > installed to use them in KDevelop?
> 
> That completely depens on your distributor. They are free to create separate 
> packages for each plugin and use dependencies to install them when the user 
> wants "Quanta" or "KDevelop".
> 
> This is out of our reach.
> 
> Note: I'd like distributors to do that, as long as they do it correct ;-)

Well, that mostly depends on how you release the tarballs.
If a Quanta release tarball contains the plugins, the distributor is unlikely
to split them out.
If you release the plugins as separate tarball(s), the distributor
is likely to follow the same pattern.

For me, the most logical way of packaging them (including making
the tarballs) would be something like:
* kdevplatform (no plugins);
* kdevelop (contains only plugins that are unusable outside of it);
* quanta (contains only plugins that are unusable outside of it);
* kdevplatform-plugins-base (the most common plugins for both);
* kdevplatform-plugins-webdev (xml, css, ...);
* (possibly) kdevplatform-plugins-php (unless it's included in webdev).
etc...

kdevplatform-plugins-webdev could be split further into separate
plugins, but it would complicate things somewhat for the users.
kdevplatform-plugins-base could be merged with kdevplatform
in case having kdevplatform without them makes no sense.

kdevelop and quanta would have dependencies upon kdevplatform
and kdevplatform-plugins-base. Additionally, Quanta would depend
on kdevplatform-plugins-webdev. All the other kdevplatform-plugins-*
packages would serve as add-ons to both.

This is just a way I would do it, but of course you may have decided
something better already.


Thanks,
Alexander