I just noticed the .desktop files in marble confuses the script used to
generate <URL: https://wiki.debian.org/MimeTypesSupport/PackageList >
because it contain 9 .desktop files:

% dpkg -L marble|grep desktop
/usr/share/applications/marble_geo.desktop
/usr/share/applications/marble_gpx.desktop
/usr/share/applications/marble_kml.desktop
/usr/share/applications/marble_kmz.desktop
/usr/share/applications/marble_shp.desktop
/usr/share/applications/marble_worldwind.desktop
/usr/share/applications/org.kde.marble.desktop
/usr/share/kservices5/marble_part.desktop
/usr/share/kservices5/marble_thumbnail_kmz.desktop
%

Is there a good reason for all these desktop files.  At elast some of
them seem redundant:
--- /usr/share/applications/marble_gpx.desktop  2017-10-20 05:52:49.000000000 +0200
+++ /usr/share/applications/marble_shp.desktop  2017-10-20 05:52:49.000000000 +0200
@@ -96,7 +96,7 @@
 GenericName[x-test]=xxVirtual Globexx
 GenericName[zh_CN]=虚拟地球仪
 GenericName[zh_TW]=虛擬地球儀
-MimeType=application/x-gpx+xml;
+MimeType=application/x-esri-shape;
 Icon=marble
 Terminal=false
 Categories=Qt;KDE;Education;Geography;

These two files could be combined into once by using

  MimeType=application/x-gpx+xml;application/x-esri-shape;

Perhaps the number of .desktop files in the package can be reduced?
--
Happy hacking
Petter Reinholdtsen

Let's start by ignoring the ones placed in KService dir. They are for plugins
for the KService library.

If I understand it correctly, it being marble and the desktop spec, all of the
extra mime types are supported by marble thru optional plugins; optional
plugins that distributions might want to carry in different binary packages, or
maybe even not carry at all, and only if the the plugin for application/x-
esri-shape is installed, marble support this mimetype.

For plugin-based software, this is makes sense.

Also e.g. okular uses the same approach. Here is the Debian package split into
two packages with the lesser used packages with heavy dependencies resides.

I hope this is sufficient response to "is there a good reason", and I think the
script you use should be adapted to work with this pattern.

Kind regards
/Sune

[Sune Stolborg Vuorela]

Note, the  script I use operate on the appstream data set, so the fix
need to be done in the input system for appstream, not in my script.  Or
in marble. :)

CC to Matthias, to make him aware.

Am Di., 6. Juli 2021 um 23:02 Uhr schrieb Petter Reinholdtsen <pere@hungry.com>:

Nah, AppStream is fine - it's just a misconception that AppStream
would work on all desktop files - it interacting with desktop-files is
mostly a convenience feature with limited applicability. The MetaInfo
files are the actual true source for metadata.
If a software ships addons, upstream needs to provide matching addon
AppStream component definitions (see
https://www.freedesktop.org/software/appstream/docs/sect-Quickstart-Addons.html
) otherwise their data will not show up in the component index (and
the addons will not be installable or removable via a GUI software
center).

Cheers,
    Matthias.