2015-11-11 7:09 GMT+01:00 Scott Kitterman <[email protected]>: > [...] > 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. -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
