search results don't match apt search

Bug #1825766 reported by Stuardo -StR- Rodríguez
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-software (Ubuntu)
New
Undecided
Unassigned

Bug Description

searching for "guake" does not show the "guake" package, but if I search it via apt, I do see it available.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: gnome-software 3.30.6-2ubuntu3
ProcVersionSignature: Ubuntu 5.0.0-13.14-generic 5.0.6
Uname: Linux 5.0.0-13-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Sun Apr 21 17:39:19 2019
InstallationDate: Installed on 2019-04-21 (0 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
InstalledPlugins:
 gnome-software-plugin-flatpak N/A
 gnome-software-plugin-snap 3.30.6-2ubuntu3
SourcePackage: gnome-software
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Stuardo -StR- Rodríguez (stuardo) wrote :
Revision history for this message
Stuardo -StR- Rodríguez (stuardo) wrote :

Another program listed in apt but not in gnome-software:
-phpmyadmin

Revision history for this message
Stuardo -StR- Rodríguez (stuardo) wrote :

Gnome says it's a package issue, not a gnome-software issue.

https://gitlab.gnome.org/GNOME/gnome-software/issues/647

Revision history for this message
Stuardo -StR- Rodríguez (stuardo) wrote :

And gnome/gnome-software ended closing that issue because they don't think it is in gnome-software's scope.

As a user, I will/should not use nor recommend gnome-software as a software management tool as I will never know if the app will be listed in it or not.

Revision history for this message
Matthias Klumpp (ximion) wrote :

You can expect to find an app in GNOME Software if it is a GUI application (== has a .desktop file in /usr/share/applications/ that isn't NoDisplay and of Type=Application). For anything else (that likely includes phpMyAdmin) GNOME Software isn't the right tool and wasn't designed for.

Apps will also definitely show up if they have AppStream metainfo files of type desktop-application (so service-types are also excluded here, currently).
Also it appears that on Ubuntu Snaps aren't filtered by type.

Revision history for this message
Stuardo -StR- Rodríguez (stuardo) wrote :

I never liked Ubuntu trying/forcing snaps, but for 19.04 I gave up and tried to embrace it. It is very hard to know when to use gnome-software, when to use apt, when to use snap. Before snaps, I was always able to find every app via apt/aptitude, but now, this is very frustrating.

IMHO, if Ubuntu is pushing snaps so hard, we need a software-tool alternative that can work with both sources.

Revision history for this message
Stuardo -StR- Rodríguez (stuardo) wrote :

Still an issue in Ubuntu 20.04. Following @ximion's explanation, Guake IS a GUI application that should be listed in gnome-software. "Ubuntu Sofware", when searching for "guake" shows

- electerm ("guake" in description)
- guake-cl (change colour)
- guake indicator

So, if it lists related apps but not the app itself, it confuses the user. The fallback was to open a term and `apt install guake`. Any non technical user, will give up.

Revision history for this message
Matthias Klumpp (ximion) wrote :

@stuardo:
The reason for Guake being missing is that the `guake.desktop` file in `/usr/share/applications` is a symbolic link *and* the application doesn't ship a metainfo file.
This is forbidden: https://wiki.debian.org/AppStream/Guidelines
The .desktop file being a symlink results in Guake basically not being seen by the metadata generator at all. To fix this, either the .desktop file needs to be an actual file, and not a symlink, or a metainfo file[1] has to be shipped with this package. Ideally both.

The reason this package is missing is simply a result of nobody caring enough to submit a patch or do a bit of work to make this app show up for a few years now (it never was in the catalog, as far as I can tell). Maybe a good case for a patch submission? ;-)

[1]: https://www.freedesktop.org/software/appstream/metainfocreator/#/

Revision history for this message
Stuardo -StR- Rodríguez (stuardo) wrote :

@ximion

thank you for your comments. I understand the symlink issue. I'm now digging in the github/guake issues, and it looks like the solutionw as to include the appdata file. Now I have the following questions:

1. Is the apppdata enought? OR both the appdata AND symlink issues need to be solved?
2. The appdata file in the package is at /usr/share/guake/data/guake.appdata.xml I see other programs adding the appdata at /usrh/share/appdata/ like /usr/share/appdata/google-chrome.appdata.xml or /usr/share/appdata/network-manager-openvpn.metainfo.xml for example. Should the appdata file for guake be /usr/share/appdata/guake.xml?

@ximion, you are right, a patch is missing, and it's time to work on that. I'll try to find the answers by myself, but if you have the answers, they will really be apreciated.

Revision history for this message
Matthias Klumpp (ximion) wrote :

On 1): The metainfo/appdata file is only enough if it is complete, so, contains an icon reference and name/summary/etc. tags. If it doesn't, then you'll need the .desktop file as well and a launchable entry.

On 2): All of these locations are wrong ^^ Metainfo files *must* be installed into /usr/share/metainfo in order to be valid. Refer to the AppStream specification (specifically https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#spec-component-location) for details.
There's also an online tool to help people making metainfo files at https://www.freedesktop.org/software/appstream/metainfocreator/#/ now

As for that existing "appdata" file, make sure it's actually an AppStream metainfo file before installing it somewhere else - maybe it just coincidentally has the same name as a metainfo file, but actually is something different.

Also, google.chrome and network-manager need their metainfo locations fixed ;-) It's likely that support for the legacy location will go away soonish (almost nothing installs files there nowadays).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.