AppStream, Discover and metadata

Matthias Klumpp matthias at
Wed Nov 11 18:08:39 UTC 2015

2015-11-11 7:09 GMT+01:00 Scott Kitterman <ubuntu at>:
> [...]
> My personal experience with PackageKit + Apper was very poor.  It was my
> experience that PackageKit's apt integration was just a thin graft on top of
> (or under depending on your perspective) something designed to work with RPM
> and really didn't work at all well in Kubuntu.

When did you try that last? Since on Debian we never had such issues,
since the switch to the aptcc backend, which performs much better than
the old Python-based apt backend.
PK itself is in no way RPM specific, in fact it even has
Debian-specific facilities built in (e.g. for Debconf support).
It is, however, relatively basic and does not support some advanced
features (like setting packages on hold) - but that's something one
doesn't do in a software center anyway.

> I don't know if it was because
> of the Apper design or inherent in PackageKit, but it had it's own package
> cache that seemed to be frequently out of sync with apt (note: aptitude
> does/did something similar and associated problems have caused me to stay far
> away from it as well).

Where did you get that idea from? PK, apt and aptcc never had their
own package cache, and always accessed the apt cache directly. There
is/was a cache for .desktop-file-->package associations, but that one
was only used to display a "launch application" dialog after
installing (and it didn't matter much if that cache was out of sync).

> In my limited free time I've been working on making QApt + Muon work better in
> Debian and if there's a newer thing in that direction to test, I'd be glad to
> test it on Debian.

Please do, but please also use a recent version of PK and QPK - the
version in Ubuntu has been outdated for years, which will be fixed
this cycle as I was told.

More information about the kubuntu-devel mailing list