drop version numbers from users' .desktop file names

[Michał Sawicz]

The version number in click .desktop file in users' ~/.local/share/applications cause issues on different levels for apparently no advantage.

Every time you want to find a .desktop file for an app, you either need to store the whole file name, with the version number (which breaks on app upgrades, unless you react to it somehow), or find a matching .desktop file based on the developer / app id and hookname every time. App upgrades / removals are tricky unless we start reacting to signals from the click system itself.

Since in users' realms there can only be one version of an app installed at any given time, it feels like exposing this complication there is unnecessary.

What do you think?

[Launchpad Janitor (janitor)]

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

[Michael Zanetti (mzanetti)]

Probably we should even think if the appId should contain the version number at all. Seeing that URL dispatcher is working around this too with appId://<id-without-version>/current-user-version.

So far I have the impression I need to cut away the version wherever I deal with appIds.

Is the same actually true for the hook name? Given that on an upgrade the hookname could change but it's still the same application it would break any stored references to an app on an upgrade.

[Gerry Boland (gerboland)]

My objection to the version number in the desktop file is due to the fact it does not respect existing desktop file behaviour that unity7 and other existing shells rely upon.

Those shells watch (via inotify) the desktop file directories and monitor file changes and removals. If a file is changed, the shell re-reads it - this is perfect for app updates to be reflected in the shell immediately - requiring no direct communication between update process and the shell. If a file is removed, shell can assume the application was removed and act accordingly.

With a version string in the desktop file name, the above mechanism will not work. If a click package updates, it will appear to unity7 that the application was actually removed.

[Jamie Strandboge (jdstrand)]

I don't think I care one way or another on if the desktop file has the version in the name (I'll let others comment). However, the APP_ID should have the version in the name since APP_ID is used to to know which apparmor profile to change_profile in to and the apparmor profile is necessarily versioned because different versions of the app may have different permissions, and multiple versions of the app may exist on a multiuser system.

[Marc Deslauriers (mdeslaur)]

Please keep in mind that different users may be using different versions of the installed applications.

[Colin Watson (cjwatson)]

I don't think anyone's going to persuade me that it's safe to change the app ID semantics, but I could introduce a new "short ID" (better name welcome) that doesn't contain the version, and then anything that doesn't need the version could switch to using that. How would that be?

[Colin Watson (cjwatson)]

In click 0.5.0 I'm adding a new "short application ID" notion which has the version removed, accessed using ${short-id}. This is only valid in user-level hooks, or in system-level hooks that use Single-Version: yes. To complete the fix for this bug, upstart-app-launch is going to need to switch to using that, and will need to bump its dependency to click (>= 0.5.0).

[Colin Watson (cjwatson)]

Correction: this will in fact be click 0.4.14. There's no change to the metadata in click packages themselves, so I won't bump the minor number.

[Launchpad Janitor (janitor)]

This bug was fixed in the package click - 0.4.14

---------------
click (0.4.14) trusty; urgency=low

  [ Colin Watson ]
  * chroot: Print help if no subcommand given (LP: #1260669).
  * chroot: Recommend debootstrap from click-dev, and explicitly check for
    it in "click chroot create" (LP: #1260487).
  * chroot: Check for root in "create" and "destroy" (LP: #1260671).
  * hooks: Add a ${short-id} expansion to hook patterns; this is valid only
    in user-level or single-version hooks, and expands to a new "short
    application ID" without the version (LP: #1251635).
  * hooks: Strip any trailing slashes from the end of patterns, as they
    cause confusion with symlink-to-directory semantics and can never be
    useful (LP: #1253855).
  * install: Extend the interpretation of "framework" a little bit to allow
    a Click package to declare that it requires multiple frameworks. This
    will allow splitting up the SDK framework declarations into more
    fine-grained elements.
  * Policy version 3.9.5: no changes required.
  * build: Enforce only a single framework declaration for now, by request.

  [ Zoltan Balogh ]
  * Add qtmultimedia5-dev to the SDK framework list.

  [ Dimitri John Ledkov ]
  * chroot: Add "cmake" to build_pkgs, as it is expected for cmake to be
    available on any (Ubuntu) framework.
 -- Colin Watson <email address hidden> Thu, 23 Jan 2014 17:30:54 +0000

[Ted Gould (ted)]

We've moved to providing an information API in UAL which doesn't require version numbers. That is preferred over the desktop files, they can be considered deprecated at this point. So this bug won't be fixed.