update-notifications, gnome-settings-daemon vs gnome-software

[Matthias Klumpp]

Hi!
Sorry for the delay...

2015-10-11 20:28 GMT+02:00 Michael Biebl <biebl at debian.org>:
> Hi Joss,
>
> I'm in the process of updating gnome-settings-daemon to 3.18.0.
> We currently ship debian/patches/01_reinstate_updates_plugin.patch in
> gnome-settings-daemon, which you added with the following changelog entry:
>
>   * 01_reinstate_updates_plugin.patch: reinstate the “updates” plugin,
>     since gnome-software is not in jessie and we need an update»
>     mechanism.
>
> We do have gnome-software in sid/testing now, so I wonder if we can drop
> the patch or if there is still value in keeping it.

Yes, please drop it - it was added when we didn't have g-s yet, and
right now it might even cause unwanted sideeffects when someone has
GNOME-Software installed (which also tries to get the role of the
update-managing service).

> gnome-software itself still looks pretty much broken in Debian.
> It's dog-slow, I can't seem to browse all available applications,
> searching for applications doesn't seem to work etc.

Yes. That party will be solved as soon as we get AppStream data. The
data itself is ready, and we discussed how to add it at Debconf. Right
now, I am waiting for the ftp-masters to implement their favourite way
to get the data from appstream.debian.org into the main archive, so it
can be downloaded from there via Apt. That unfortunately seems to take
some time...

> So I'm not sure if gnome-software is ready yet.

Another thing which we would need is support for parallel transactions
in PackageKit's aptcc backend. That is not an essential feature, but
it would improve the speed of GNOME-Software a lot. Unfortunately,
this is not a trivial task, since libapt isn't threadsafe, so we would
need to create a multiprocess solution.
Since upstream mostly cares about Fedora, where they wrote a new (and
now threadsafe!) package-manager from scratch, it's highly unlikely
anything will happen to solve performance issues when reading data in
GNOME-Software or PackageKit.
Another thing is that the libappstream-glib library, which
GNOME-Software uses instead of libappstream, always parses all XML or
YAML data again and creates an in-memory cache of that stuff. ASGlib
has a very efficient parser and is usually very fast, but I have seen
it performing less well under memory pressure, compared to my own
Xapian-based libappstream.
The biggest bottleneck here is, as said, non-parallelized and very
slow PackageKit queries (which will become less if g-s can read the
data it wants from DEP-11 / AppStream data).

> Does anyone have better experience with gnome-software and knows what's
> missing here?

I'm the maintainer of the AppStream specification, and regularly
talking to Richard, the maintainer of GNOME-Software (and biggest
consumer of AppStream metadata so far). I also sometimes contribute to
GNOME-Software, so if you have any further questions, please ask :)

Regards,
    Matthias

-- 
I welcome VSRE emails. See http://vsre.info/