Aaron J. Seigo aseigo at
Fri Oct 17 16:18:44 BST 2008

On Thursday 16 October 2008, Albert Astals Cid wrote:
> I'm worried by how it could hurt playground/sysadmin/shaman afair it's a
> similar tool to kpackagekit and choosing one over the other as
> default "might" hurt the community.

so i spent the time this morning to build an dinstall both the shaman and 
kpackagekit projects. here are my thoughts:

* neither are ready for inclusion in a kde release yet, but both show promise.

	* kpackagekit is close to ready, but it needs a GUI review (not just strings; 
some of the dialog based interaction is rougher than it should be) and testing 
across platforms (hard to get when its in playground). we also need to finish 
out the KDE policykit UI

	* shaman could well become the replacement for kpackage, but needs more 
backends; it didn't work on the opensuse laptop i'm writing this on, for 
instance, and all i got on it was a dialog saying "Pick a backend:" with no 
options listed and a blank mainwindow

* i think both have very different use cases and patterns, and in this case we 
may want both.

	* kpackagekit might make the most sense in kdebase/workspace: it integrates 
with systemsettings at its primary mechanism (at least, that's what it seems 
from looking at it this morning and a bit last night) and fills the "here's 
your desktop, here's the basic install/remove system" gap. i don't think it 
makes tons of sense outside of the KDE workspace, since other platforms 
provide this UI service already

	* shaman probably makes most sense in kdesysadmin. it's more of a full 
featured, do-it-all package management interface, much like kpackage is/was. 
it has a different audience and purpose that kpackagekit imo.

* it would be great to get distro maintainers to weigh in on the issues here 
as well. if we can get commitment-backed-by-effort from the distros on these 
tools, then we know we won't be wasting our time (like we were, for better or 
worse, with kpackage) and that these tools will get enough real world usage to 
make sense as members of our main packages

so, in summary, my personal recommendation is:

* shamanin kdesysadmin in 4.3 at the earliest, but only once it has great 
backend coverage, perhaps debut it earlier in extragear first for a couple of 
independant releases

* kpackagekit in kdebase-workspace for 4.2 or 4.3, depending on the effort that 
the developers can put in between now and nov 17th on smoothing the rough 

* start courting downstreams to get feedback on these tools

Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the kde-core-devel mailing list