Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Omitting ".desktop" suffix is allowed #146

Closed
jnumm opened this issue Jan 13, 2017 · 6 comments
Closed

Omitting ".desktop" suffix is allowed #146

jnumm opened this issue Jan 13, 2017 · 6 comments

Comments

@jnumm
Copy link

jnumm commented Jan 13, 2017

This is the same bug as ximion/appstream#100.
If the id of a desktop application does not end in ".desktop", appstream-util validate will complain <id> does not have correct extension for kind. That is incorrect as the specification tells us

For applications, the tag value must be the same name as the installed .desktop file for the application, the .desktop suffix of the filename may be omitted.

Omitting the ".desktop" suffix is not an error.
A relevant line: https://github.com/hughsie/appstream-glib/blob/master/libappstream-glib/as-app-validate.c#L1111

@hughsie
Copy link
Owner

hughsie commented Jan 13, 2017

Whilst I agree that in the spec it says that, a good proportion of the tools that generate and consume AppStream XML will currently break if you omit the .desktop suffix. I was talking to @ximion yesterday about this, and we need more details in the specification to deal with when the application ID does not match the appstream ID. Until we've got it sorted out in the spec, and a good majority of tools don't break, I think including the .desktop in the is a very good idea.

@ximion
Copy link
Collaborator

ximion commented Jan 13, 2017

@hughsie The spec is fine and this change has been in production at Debian for almost a year without noticeable breakage - the only thing that is potentially broken is launching such apps in GNOME Software, all other tools using libappstream are fine (since libas had a get_desktop_id() method for that purpose for a very long time).

So, I think this is a safe change, if done right with appropriate fallback code.

That being said, I still would like to have an explicit tag in AppStream to specify a way to launch apps (by command, dbus-activation or desktop-id), to get rid of some automagic and to support the case of desktop-app components not having a directly associated launchable .desktop file (or multiple files, for that matter - think of software suites (rare, but they exist)).

@hughsie
Copy link
Owner

hughsie commented Jan 13, 2017

Okay, I'm fine with removing the validation warning. I'm not fine removing the validation warning before we talk about XML API on how to launch apps.

@ximion
Copy link
Collaborator

ximion commented Mar 17, 2017

Getting the launchable proposal through would solve this issue in a very nice way ( https://lists.freedesktop.org/archives/appstream/2017-March/000148.html ) ;-)

@hughsie
Copy link
Owner

hughsie commented Mar 17, 2017

Right, this depends on that.

@ximion
Copy link
Collaborator

ximion commented Aug 5, 2017

It's solved now... ;-)

@hughsie hughsie closed this as completed in 0facd79 Aug 6, 2017
bbarenblat added a commit to bbarenblat/debian-transmission-remote-gtk that referenced this issue Nov 24, 2018
Notably, set a minimum version requirement for appstream-util. Prior to
0.7.2, `appstream-util validate` would complain if your application ID
did not end in `.desktop`. That requirement was dropped as a result of
hughsie/appstream-glib#146;
transmission-remote-gtk began taking advantage of the looser checking
in dd01b09.

Also add an explicit dependency on libappstream-glib-dev, which was previously
being pulled in as a transitive dependency.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants