Hi everyone!
Sorry for the delayed reply, I was busy with traveling around during
the new year. For that matter: Happy new year! :-)
I am the upstream maintainer of AppStream as well as in Debian.
Am Mi., 1. Jan. 2020 um 13:17 Uhr schrieb Jeff <jf...@posteo.net>:
>
> Firstly - apologies for sending this to -devel. Please point me at a
> better place to ask the question if there is one.
I don't think there's one explicitly for Debian. The Freedesktop
mailinglist occasionally gets distro-related questions, and if you
suspect a bug a report against src:appstream will work. But I am also
fine with this on d-devel.
> One of my packages is an application and ships a .desktop file and
> appstream xml. The tracker.debian.org page for the package complained
> that the ID for package didn't follow the {tld}.{vendor}.{product}
> scheme[1], so I modified so that it did.
>
> Now I have a report from a Gnome 3 user that since the above change, it
> is no longer possible to add the application as a "favorite".
To clarify: Do they claim it's no longer possible to add the app as
favourite in GNOME Shell, or in the GNOME Software app?
> [...]
Am Mi., 1. Jan. 2020 um 21:35 Uhr schrieb Simon McVittie <s...@debian.org>:
>
> On Wed, 01 Jan 2020 at 13:17:34 +0100, Jeff wrote:
> > One of my packages is an application and ships a .desktop file and
> > appstream xml. The tracker.debian.org page for the package complained
> > that the ID for package didn't follow the {tld}.{vendor}.{product}
> > scheme[1], so I modified so that it did.
>
> My understanding is that downstream distributors like Debian should
> not be changing the AppStream ID: this is something that should be done
> in a coordinated way by the package's upstream developers, so that all
> downstream distributions (both traditional OS distributions like Debian
> and Fedora, and app frameworks "above" the OS like Flatpak and Snap)
> end up using the same ID.
Exactly, and this is actually a very important thing in AppStream. IDs
should be static and shouldn't be changed by individual downstream
projects, because that makes the software component essentially a
different one in the eyes of AppStream. That can lead to multiple
issues, like tools using the data getting confused when fetching
information about the software, or ratings and reviews not getting
attributed to the right software.
The validator hint exists to basically forward this issue upstream and
ask them to change the ID if it's a new application - new AppStream
metainfo files should ideally not ever start with a non-reverse-DNS
ID. That the other scheme exists is a mistake of the past, which we
will now support forewer. This also means that if the app doesn't
follow the rDNS scheme, they may not want to change the ID if the old
one has been established for years. That's fine too in that case.
A way to transition IDs exists by putting the old ID as a provided ID, like so:
```
<id>tld.domain.MyCoolApp</id>
<provides>
<id>mycoolapp.desktop</id>
</provides>
```
Some tools (but not all!) will do the right thing then and merge
external data associated with both IDs.
Since the warning originates from the upstream metainfo file
validator, the message is light on info about what we as a
*distributor* should actually do.
I am very tempted to implement a way to override this particular
message to make it much more clear to Debian developers on what to do
here, or maybe even to potentially hide this particular issue from the
developer dashboard / issue pages (not sure what is better here, the
former feels a bit more honest to do). Do you (Simon, Jeff, Mattia)
have any preferences / ideas on that?
> The AppStream ID and the .desktop filename will usually also need to be
> coordinated. For example, GNOME Builder (package name and executable:
> gnome-builder) ships /usr/share/applications/org.gnome.Builder.desktop,
> which means its freedesktop.org app ID (derived from the .desktop file)
> is "org.gnome.Builder.desktop", and its AppStream ID needs to be either
> "org.gnome.Builder.desktop" or "org.gnome.Builder". (In fact it's the
> latter, so it has /usr/share/metainfo/org.gnome.Builder.appdata.xml.)
>
> Again, any changes to the .desktop filename should happen upstream first.
It was this way in the past, but nowadays AppStream is *way* more
explicit. Older versions of AppStream were a pretty useful hack to
"just get the info we need quickly" and were tailored much more for
being autogenerated data for distributions. Nowadays, with newer
versions, a lot of the magic has been drained from the spec and pretty
much every change should now be explicit, focusing much more on making
metainfo files easy to write and understand by humans.
That means in this case in particular: You can pick literally and rDNS
name for your component that you want, as long as no other app is
using it already. That creates a component that is, initially, not
launchable. This is sometimes desired, for example WINE is a
type=desktop-application GUI application that doesn't have a "main
app" that works on its own and can be launched from the software
center. Yet, it fits the "GUI application" definition a bit more than
the one of a console application.
Most apps do want to be launched from the software center though,
those simple set their desktop-id via a <launchable/> tag:
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-launchable
E.g.
```
<id>org.gnome.Sysprof2</id>
<launchable type="desktop-id">org.gnome.Sysprof2.desktop</launchable>
```
A desktop-id isn't always the .desktop filename, but in >90% of all
cases is (refer to the desktop-entry spec for that).
The launchable type also allows other kinds of apps to be launched,
e.g. services via their systemd service files, or we apps via an URL,
but that's out of scope for gui-applications.
> > Now I have a report from a Gnome 3 user that since the above change, it
> > is no longer possible to add the application as a "favorite".
>
> GNOME Shell stores favourite apps as a list of freedesktop.org app IDs
> (basically the basenames of .desktop files).
>
> > It seems that adding an application is only possible in Gnome 3 if the
> > ID is exactly the same as the executable name.
>
> There are several linked identifiers that should ideally be the same:
> the .desktop file, the AppStream ID, the Wayland xdg_toplevel app ID
> (if using Wayland), the X11 RESOURCE_NAME (if using X11), the X11
> class name and window class (if using X11), and the D-Bus-style
> reversed-domain-name GApplication name (if using GApplication). Many of
> those are derived from each other, and from higher-level application
> metadata, by libraries like GLib and GTK. In the GLib ecosystem they
> cannot all have the right defaults for the reversed-domain-name naming
> style, particularly in older code that doesn't use GApplication, because
> that would be a backwards-compatibility break.
>
> If you're using GLib, check that g_get_prgname() (which defaults to the
> basename of the executable) is what you want it to be. When using a
> reversed-domain-name app ID but not using GApplication, passing the
> D-Bus-style reversed-domain-name to g_set_prgname() might be necessary.
While it is the sensible thing to do for most apps to make the
AppStream ID the same as e.g. their D-Bus name and rDNS .desktop
filename (for the reason, the AppStream validator enforces D-Bus
naming restrictions on rDNS ID strings), applications shouldn't expect
that to be the case, especially in the case of AppStream IDs. It is
absolutely possible, and I've seen examples in the wild, that one
AppStream ID actually describes on application / suite of tools that
contain multiple launchable smaller apps. LibreOffice could do that,
for example. Some apps also install multiple .desktop files to launch
the same application in different "modes".
So, if any software *does* make that assumption, it's an error and
should be fixed. GNOME Software should prefer <launchable/> data over
doing any guessing on the component-ID when dealing with an
application's .desktop file (launching it, adding oit to Shell
favourites, etc.). I also was dead certain that it was already doing
that, but I am not so sure anymore. I'll have a look at the code later
today, just to be sure.
@Jeff Did your changes include adding a launchable tag? If not, adding
one may already fix this issue.
> > Given there seem to be plenty of gnome-* applications that use the
> > {tld}.{vendor}.{product} scheme, I seem to be missing something.
>
> It might be helpful to find an application written with the same
> library stack as yours that moved from name-of-executable.desktop to
> com.example.App(.desktop) as its app ID, and check what else changed
> during that transition.
When transitioning:
1) Make sure you add a launchable tag - it may not be essential, but
it certainly is more explicit. Also, you'll get a validator info hint
if you don't have one.
2) Add the old ID to <provides/>, so tools can still associate older
data with the new name (if they Δ‡are about that)
I hope that helps! Also, many thanks to Simon for already answering
most of the questions in detail :-)
Cheers,
Matthias
--
I welcome VSRE emails. See http://vsre.info/
