meta-packages and missing-desktop-file

[Beuc]

Hi,

From https://wiki.debian.org/AppStream/Guidelines

AppStream metadata is to be placed in the /usr/share/metainfo/ directory and must be placed in the package which should be installed in order to get the software described by the respective metadata. This means that you might need to move the *.metainfo.xml or *.appdata.xml to the right (meta)package.

In case your AppStream metadata is describing a desktop-application (you can tell by the XML root-node having a type="desktop-application" or type="desktop" attribute), the .appdata.xml file must be placed in the same package as the .desktop file already is, which (as above) must be the package containing the application itself.

In my case I have a freedink-engine package which is the game itself and the editor, and a freedink-dfarc package that allows launching the games with different options and managing game extensions.

I move the .appdata.xml file in the "freedink" meta-package, so users install these 2 recommended components (freedink-engine and freedink-dfarc), but now it cannot find the .desktop file(s) in the dependent packages.
https://appstream.debian.org/sid/main/issues/freedink.html

It does not make sense to move the .desktop files in the meta-package, since the packages are independent and can be installed separately - in which case they do need their .desktop files, they can't depend on the meta-package for that.

Note: I didn't add a <launchable> tag yet, I didn't know about it, but from the wiki page and the hint it doesn't sound like this would make a difference.

I thought the generator would be able to locate the desktop files in different packages (just like I expect it to find the game translations in another package).
What do you think?

(by the way, is there a way to test the distro processing of my .appdata.xml without uploading and waiting for a few days?)

[ximion]

You need a .desktop file present to complete missing information from the metainfo file, e.g. name and summary.
The .desktop file must be in the same package as the metainfo file for two reasons: To ensure the application is actually launchable after installation, and because hunting down yet another file across the whole archive would be even more expensive (every time we need to do this, performance is reduced a lot, which is already bad enough for icons and locale).

So, you could move the metainfo file to freedink-engine and have that package recommend freedink-dfarc (that's what the recommends relation is for!), or shuffle things around so the actual launchable binary is where the metainfo and desktop file is.
Is freedink-engine useful without the freedink-dfarc package? If not, they should probably be one package anyway. If that's not the case and you actually want to have the user install/remove the -dfac package, you can also consider making it an addon: https://www.freedesktop.org/software/appstream/docs/sect-Quickstart-Addons.html - that way, users can decide to install/uninstall the component (and via a package recommends you can ensure it usually gets installed by default).

[Beuc]

If not, they should probably be one package anyway.

Not necessarily, e.g. freedink-engine depends on freedink-data which is from another source package and has its own release process. Beware of hasty "should" :)

I already have a Recommend so I'll go with that and possibly look into add-ons, thanks for the pointer.

I see you didn't answer about an easy/quick way to fully test appdata integration before uploading, I guess there's none, especially with different distros doing things with their own variants and with different pieces of software. This makes it quite time consuming and stressful for upstream to test and properly integrate the application - well, such is life :/

[Beuc]

Thanks for the fast answer, too, appreciated :)

[ximion]

@Beuc You can run basic validation with appstreamcli: appstreamcli validate-tree /install/target/dir/ or validate directly via appstreamcli validate <metainfofile>.xml.

As for the full packaging test, there is no way around running appstream-generator locally, as those tests simply require a full Debian repository to produce any useful results. There is a (purposefully) undocumented process-file command to process one package file without a full repository, but that's not a well-tested feature yet and is usually also used in combination with a "real" package repository.

[Beuc]

Thanks for the pointers.
We can add appstream-util validate that does other lint tests.
They help, though none of these prevented my latest issues.

[ximion]

@Beuc That's why I suggested the validate-tree mode of appstreamcli, which catches at least some of the issues if they are not related to packaging (e.g. things like a .desktop file naming discrepancy)

[Beuc]

Hi,

I did see validate-tree (thanks again for the pointer) but as I said that didn't help detect my latest issues ahead of time, not for split-packaging issues, not for non-standard locale path, not for icons that are too small. For all of these I have to backport the metainfo in the distros where I directly package my own application, upload new versions, and wait for a cron. For Debian fortunately this is daily I think, for Fedora I have yet to see it re-run. This results in a time-consuming and high-latency testing process :/

I am not saying we can do much given the architecture design of appstream, I'm just giving upstream feedback. I tend to think a FreeDesktop service to register and update the metainfo, as a post-release process, offering pointers to the supporting distros logs, possibly with a manual refresh trigger, may have been better, but that's probably not the time and space to discuss this :)

[ximion]

Additing tests for icons is maybe something we could have in validate-tree, however anything else is dependent on the distribution's packaging, so you really need the full archive for that.

Maybe it makes sense to publish the databases asgen uses in Debian, so people can relatively easily test their packages locally (those databases are huge though, and architecture-dependent).