evince not listed

[Sebastien Bacher]

Using current xenial, evince is not listed in gnome-software. The log states it's of unknow application type ... could it come from the fact that the .desktop is in the -common binary?

[Sebastien Bacher (seb128)]

even without the unknown application type check it seems it doesn't get correctly listed

[Dave Morley (davmor2)]

Shows up in apps scope which I assume is as expected as the app is installed

[Robert Ancell (robert-ancell)]

What's happing in this case:
1. The apt plugin states that evince-common is installed.
2. The appstream plugin attempts to find the metadata for this.
3. appstream-glib has multiple entries for the package "evince-common", it picks the first one ("evince-psdocument").
4. evince-psdocument doesn't have a type, so GNOME Software rejects the metadata.

I'm not sure why there's multiple appstream entries for this.

I suspect that moving the .desktop file into the main binary will probably solve this and it seems like the right thing to do anyway. I'm not sure if there's other cases that may be hit by this issue and what the solution is for them.

[Robert Ancell (robert-ancell)]

I built a local version with the .desktop file moved and the appstream data manually edited and it worked.

I've made the packaging change here in lp:~robert-ancell/evince/ubuntu-lp1553156
Seb - can you give a second opinion if you think moving the .desktop file makes sense and can you double check it has the correct Breaks/Replaces for this?

[Robert Ancell (robert-ancell)]

Also, I noticed the Ubuntu reviews are on the 'evince' package - there are none on 'evince-common'. So moving the .desktop file also makes them show correctly.

[Robert Ancell (robert-ancell)]

(Though now I need to double check if the reviews are source package names or binary names...)

[Iain Lane (laney)]

On Debian evince is at least listed, so I'm not sure why that doesn't work for us and I think it should (but see the next paragraph).

I think there's a second bug, besides it not being listed, that it will try to install evince-common because that's what appstream says the package is for evince.desktop. I wonder if the generator could do something about that like search for the Exec= binary - ximion? This is broken on Debian too FYI: if you remove and re-install evince then you only get evince-common. Moving the .desktop file would be a valid fix but will only fix this case.

> laney@nightingale> appstreamcli search evince.desktop
> Identifier: evince.desktop [desktop]
> Name: Evince
> Summary: View multi-page documents
> Package: evince-common
> Homepage: https://wiki.gnome.org/Apps/Evince
> Icon: evince-common_evince.png

The evince-* entries are metainfo files (not .appdata) that I think describe the different types of files that Evince can show. They aren't applications and so shouldn't be influencing the top-level list, instead being shown as sub entries in Evince's. https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html

[Matthias Klumpp (ximion)]

> I wonder if the generator could do something about that like search for the Exec= binary - ximion?

Nope, because this would mean searching the *reverse dependencies* of a package, or once again turning to the Contents file, which is always bead, because, as you know, it's super-slow.
While I see a case for searching dependencies for icons, in case of the .desktop file I would rather add an additional check to the generator to ignore the component if .desktop file and binary are not in the same package, because that happening is a bug. The .desktop file and the binary must be together, so the application only shows up in menus when it is actually installed.
Otherwise, if people only have -common installed for some reason, they will get a dead link in the menu.
Just like we don't separate manpages and binaries, .desktop files and binaries belong together too.

So, maybe we want a check for this in the generator (priority error), which is pretty easy to do...
(I am also wondering if there is policy for this... I'll do some research on what is common practice there, probably lintian should check if binary+.desktop-file+metainfo are together in one package, unless there are cases where separating is actually useful (can't think of any right now)).

[Launchpad Janitor (janitor)]

This bug was fixed in the package evince - 3.18.2-1ubuntu4

---------------
evince (3.18.2-1ubuntu4) xenial; urgency=medium

  * debian/control:
    - Set breaks/replaces for .desktop file moves
  * debian/evince.install:
  * debian/evince-common.install:
    - Move .desktop files from -common to the main binary (LP: #1553156)
    - Remove reference to obsolete evince-gtk.desktop

 -- Robert Ancell <email address hidden> Tue, 08 Mar 2016 21:40:27 +1300

[Iain Lane (laney)]

That's what the TryExec= key is for, which evince has.

I'm still not convinced it is an error, but if people want to do the work to the packages instead then that is fine.

You would do this:
  1) Find .desktop file in package 'a'
  2) Look for TryExec or Exec in that package
  3) If not there, go and look in Contents
  4) Check those packages for a Depends relationship on 'a', set that as the package for the component.

[Matthias Klumpp (ximion)]

Thing is: If we allow those separations, we would also need to allow putting the metainfo file in an arbitrary package, so in the end, in the worst case, we need to run a global archive wide or dependency- and reverse-dependency based search on the metainfo file, the .desktop file and icons.
At least with the current generator's speed, that will consume resources. So right now, I am not sure if we want to have the tradeoff of putting two most of the time arch-independent files together with the binary (and consume slightly more space in the archive), or have longer processing times when generating the metadata.
Since I am not a fan of the TryExec line[1] and separating .desktop files and metainfo, I would strongly prefer to adjust the packaging, since it also appears to be a rare event that the files are separated.
This of course diverges from what people are used to do for a long time now, which is a downside.
I still can be convinced that doing that archive wide hunt for the right file is the way to go, but at time I am questioning if it is worth to go through all that trouble if people could just fix the package once and avoid us doing that search again and again with every new upload.
I will ask around at other AppStream-enabled distros how they handle it, maybe they have some useful input.

Btw, the appstream-generator rewrite I am working on is a massive improvement in terms of speed over the older one, but even that one spends a huge amount of time on getting contents information from packages and decompressing .deb files - so searching for files which aren't in the contents file by e.g. going through dependencies will still be an expensive operation.

[1]: Desktops not only have to hunt down the icon, but *also* have to search through $PATH to check that a specific binary exists, which slows down loading all .desktop files. Caching the data isn't as easy as it is with icons too, since the binary could vanish (theoretically) at any time, and desktops would need to hide the launcher then. An icon gone missing at least doesn't affect the function of the launcher.

[Matthias Klumpp (ximion)]

Okay, looks like nobody does the archive-wide data-hunt, and all fix their packaging or didn't have that problem (asked Arch, Fedora, got fuzzy reply from OpenSUSE because I couldn't find someone directly involved with this stuff).

So I would right now rather like to add an error hint warning about missing binaries / metainfo / .desktop files, instead of making the metadata extractor more complex to accomodate for few packages shipping .desktop file and metainfo in a package separated from the project's main binary.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[corrado venturini (corradoventu)]

I have same problem also for inxi: not listed in gnome softare but ok in the old ubuntu software center

[Amr Ibrahim (amribrahim1987)]

inxi is not listed because it's a script, not a GUI application. GNOME Software is designed to show only applications. If you are familiar enough to use scripts from the CLI, you can also use apt to install it.

[corrado venturini (corradoventu)]

but inxi is listed in the old ubuntu software center - see attachment in my previus post.

[Amr Ibrahim (amribrahim1987)]

Yes, you are right. The two software centres are designed differently. Ubuntu Software Centre can show every package if you select so. GNOME Software does not; it's by design to show only applications.

[Amr Ibrahim (amribrahim1987)]

Its purpose is to encourage developers to polish their applications to comply with AppStream specifications to make them appeal to normal users.