On Wed, Nov 11, 2015 at 8:24 PM, Scott Kitterman <[email protected]> wrote: > On Wednesday, November 11, 2015 07:08:39 PM Matthias Klumpp wrote: >> 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. > > It was several years ago (probably 3 - 5, but I don't recall). I don't have > any more recent experience, so I'm sure it could have changed. > >> > 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). > > Back when I tried it, I regularly saw cases where there were updates that apt > was aware of that apper was not. Also, I recall that the only way to > determine if additional packages would need to be installed along with a > package upgrade was to do a dry run upgrade internally and then if it failed, > additional packages were needed. > > As mentioned above, this was a long time ago and I have not kept up to see if > things have changed. > >> > 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. > > I'm using whatever is in Debian. > > Scott K > > -- > kubuntu-devel mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
IMHO Apper usage is completely unrelated to this transition. In fact, I doubt that Apper is up to speed yet. The port to Qt5 is very recent and it will lack features that an apt-centered alternative can offer (such as Muon or Synaptic). Aleix -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
