Appstream ID and Flatpak

[Alexander Larsson]

Ugh,. accidentally dropped the list, adding back in.

On Thu, Dec 14, 2017 at 5:12 AM, Matthias Klumpp <matthias at tenstral.net> wrote:
> 2017-12-13 14:35 GMT+01:00 Alexander Larsson <alexl at redhat.com>:
>> On Tue, Dec 12, 2017 at 6:05 PM, Matthias Klumpp <matthias at tenstral.net> wrote:
>>> 2017-12-12 9:33 GMT+01:00 Alexander Larsson <alexl at redhat.com>:
>>>> [...]
>>>
>>> Something like this:
>>> ```
>>> <component type="desktop-application">
>>
>> desktop-application? Did things change again? We had to do all sort of
>> workarounds for the metainfo change as well, and we can't rely on
>> implementations supporting this new type (in fact, the version of
>> libappstream-glib in the freedesktop runtime that we use doesn't
>> support this, nor will the gnome-software version in the host on older
>> distros), so we can't rely on this anyway.
>
> Well, the problem here is appstream-glib, which is not the reference
> implementation of AppStream, therefore mismatches happen. There is
> some stuff in asglib that isn't in libas and vice versa, and sometimes
> features get implemented in one library earlier than in the other.
> Richard and I are working on resolving that issue though, and I am
> confident that we can fix any mismatches at some point (that's what
> the formalized specification is for).
> In this particular case, "desktop-application" as a component type is
> supported in libappstream for about two years, and in appstream-glib
> for more than a year.
> Also, it's no reason to panic, as we will never ever remove the
> "desktop" alias. So, writing `<component type="desktop">` would work
> just as well here, and will continue to work forever. (And I should
> probably have used that here to not trigger that confusion, but muscle
> memory was stronger).

Well, reference implementation or not, if a spec is stable you should
be able to use any implementation you want. I realize that the two
implementations are slighly different in this respect, but in practice
current users of the appstream xml that e.g. flathub produces use
appstream-glib, and if that contains a component type that in-use
versions of asglib doesn't understand (for example on rhel or debian
stable), then users might not see some apps.

>> In fact, we may have to back-patch it to type="desktop" as upstreams
>> start migrating to this...
>
> A lot of them already did, I think. Why does the version of asglib in
> the Freedesktop runtime matter at all? (and could you update it? it's
> ABI-stable afterall) I also don't know what asglib throws out as
> default when it writes metainfo files, I would guess that it writes
> "desktop" for compatibility reasons though.

When the build is done, flatpak-builder runs appstream-compose (in the
sandbox) to combine the appdata file, the desktop file and the icons
into a single "share/app-info/xmls/$appid.xml.gz" file (and icons
dir). If the version of asglib in the sdk (currently 0.7.2) doesn't
know how to handle the new desktop type i'm not sure what it will do,
but it will probably not rewrite it to type=desktop, so my guess is
that it will end up as type=desktop-application in the final xml in
the flatpak repo, which some readers will not understand.

Ideally it should be renamed to the most widely supported versions,
and since flatpak overall is pretty new I'm sure we can tweak the
stability guarantees a bit and rev asglib, but long term this is not a
realistic way to work, old deployments must continue working.

>> Is there some way we could that this that would actually work with
>> older appstream consumers? For example, if we had to rename an
>> upstream id of foobar.desktop as to org.app.Foobar.desktop, could we
>> add in some kind of alias with the original id?
>
> You could, but you would need a newer AppStream for that. I wonder
> whether it would make sense to just force upstream projects to rename
> their .desktop files or print a big fat warning when they don't do
> that.
> Using the old "component-id is the .desktop filename" logic, the only
> way to ensure people can flatpak their application and do not rename
> the component-ID specifically for Flatpak bundling is to make them
> rename the ID and .desktop file in their source tree, instead of
> overriding it just for the build.
> This has the upside of fixing the issue, being 100% forward- and
> backward-compatible and getting more .desktop files to follow the
> reverse-DNS scheme. The downside is the .desktop file rename messing
> with user-created links on desktop-environments, which is the known
> problem with doing that. But IMHO this has to be done anyway at some
> point, so why not take Flatpak bundling as an incentive to finally do
> it?

Obviously the goal is for the packaging changes needed for flatpak to
go upstream, and in many cases this is happening. However, it is not
realistic that all upstreams will automatically change how they do
things because of some new packaging system that is not used all that
much yet. Also, many apps we package has no appdata at all, so we just
make some up, which could diverge from how other people package it.

As for the reverse dns names, are you following the changes in how
they are recommended toi work:
https://bugs.freedesktop.org/show_bug.cgi?id=103216
If you have some document describing how the id should be chosen, it
would be nice to update it to follow that.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                Red Hat, Inc
       alexl at redhat.com         alexander.larsson at gmail.com