AppStream, Discover and metadata

Aleix Pol aleixpol at kde.org
Thu Nov 12 00:22:26 UTC 2015


On Wed, Nov 11, 2015 at 8:24 PM, Scott Kitterman <ubuntu at kitterman.com> wrote:
> On Wednesday, November 11, 2015 07:08:39 PM Matthias Klumpp wrote:
>> 2015-11-11 7:09 GMT+01:00 Scott Kitterman <ubuntu at kitterman.com>:
>> > [...]
>> > 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
> kubuntu-devel at lists.ubuntu.com
> 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



More information about the kubuntu-devel mailing list