New symlink behaviour in master

[Richard Hughes <hughsient gmail com>]

Hi all,

I've just checked in some functionality into master that automatically
symlinks the appstream-enabled flatpak remotes metadata into
~/.local/share/app-info. I thought I should explain a bit what this is
trying to do, and how it works.

Before this change we were just being really dumb in the
appstream-glib code looking a few hardcoded flatpak locations and then
adding every appstream.xml file we find. So if the remote is disabled,
or removed (and we don't manually remove the appstream.xml file) we
add it to the global store regardless creating confusion in the UI. We
also carried a ton of hacks in appstream-glib to cope with the flatpak
directories being special, for instance looking at the name of the
../../ folder to get the remote name as all flatpak appstream files
have a origin hardcoded to "flatpak" and having to inotify various odd
things to make it all hang together.

When we added a new remote we relied on appstream-glib to pick up the
inotify change and for the store to be sensibly updated, which doesn't
work so well when we're replacing appstream metadata in-place, and
when we have user and system flatpak repos with the same name. It
always felt a layering violation teaching appstream-glib about the
inner workings of flatpak, and to fix it properly would have meant
depending on libflatpak, creating a nice dep loop that would be up to
the distros to work out. Logically the flatpak-specific stuff belongs
in the flatpak gnome-software plugin, or in flatpak itself.

So my idea was thus:
 * Don't load the flatpak locations in any special way in
appstream-glib; go back to just loading the standard app-info
locations
 * Encode the user-specified remote name in the symlink itself (as the
user is free to choose any remote name)
 * Set up symlinks into app-info so that appstream-glib loads the
metadata and icons and watches them for changes
 * Keep these symlinks up to date using the
FlatpakInstallation::changed() signal.

This approach also means it'll work with the other appstream-using
software centers. Perhaps this will be a first stage doing it in g-s
and then I could propose to Alex that libflatpak takes over the role.
With the new patches it is now predictable when things get added, and
we can fix the problem where adding a remote required restarting
gnome-software before everything worked quite right.

So, if you see any random output like:

[hughsie hughsie-work gnome-software (master %)]$ ls
~/.local/share/app-info/xmls/ -l
total 232
-rw-rw-r--. 1 hughsie hughsie 203575 Jun  8 13:56 extensions-web.xml
lrwxrwxrwx. 1 hughsie hughsie     76 Jun  8 13:35
flatpak:gnome-nightly-apps.xml.gz ->
/var/lib/flatpak/appstream/gnome-nightly-apps/x86_64/active/appstream.xml.gz
lrwxrwxrwx. 1 hughsie hughsie     71 Jun  8 13:35
flatpak:gnome-nightly.xml.gz ->
/var/lib/flatpak/appstream/gnome-nightly/x86_64/active/appstream.xml.gz
-rw-rw-r--. 1 hughsie hughsie  10933 Jun  8 13:56 steam.xml.gz

...you know what's happening! :)

Richard.