Initial standalone Plasma::Package repository

[Marco Martin]

Hi all,

first, brief introductionon what this is:
during a Bof about scripting in applications at Akademy it occurred that some 
applications may be interested by the functionality provided by 
Plasma::Package, provided it was on a lower tier.
Since I already had kindof the idea of making Package an independent 
framework, I started a scratch repo in which i isolated just Package (and a 
piece of PluginLoader, but not sure that will ultimately stay there)

http://quickgit.kde.org/?p=scratch%2Fmart%2Fpackage-standalone.git

the history right now would use the graft thing like other frameworks, if 
better, an attempt with filter-branch may be done as well.

right now the dependencies are down to:

 * Qt5Core
 * Qt5 (required version >= 5.2.0)
 * KF5Archive (required version >= 5.2.0)
 * Gettext
 * PythonInterp
 * KF5I18n (required version >= 5.2.0)
 * Qt5Xml (required version >= 5.2.0)
 * KF5Config (required version >= 5.2.0)
 * Qt5DBus (required version >= 5.2.0)
 * KF5DBusAddons (required version >= 5.2.0)
 * KF5Service (required version >= 5.2.0)
 * ECM (required version >= 0.0.9)
 * Qt5Test (required version >= 5.2.0)
 * KF5CoreAddons


some of those may even be removed still (dbus is used to trigger kbuildsycoca, 
but we want to eventually move this stuff out of sycoca)


right now all the classes are still under the Plasma namespace, and should 
probably be renamed and cmakes to be cleaned up (especially because it would 
be used by plasma too to the two identically named classes, new and deprecated 
would clash)

may be KPackage/KPackageStructure? (seems to clash only with an ancient KDE2 
app)

Another thing is the plugin loading, the sub part of PluginLoader should 
probably be kept, maybe in the form of
KPackageTrader, that would support also api for trader queries

Comments/things that should be done there? missing features?

-- 
Marco Martin