structure of desktop file directories

[Simon McVittie]

On 04/10/13 11:11, Jerome Leclanche wrote:
> This seems like an implementation detail leaking into the spec. Why
> should the lib assume the caches are out of date based on the
> timestamp on applications/? System-wide changes are expected to run
> u-m-d.

I think what Ryan is trying to solve here is:

* we currently have a cache for MIME associations, but no cache
  for "all the applications"
* things like GNOME Shell spend quite a long time reading lots of small
  .desktop files, and would be substantially faster to start up
  if they could read one large cache instead
* unlike the MIME database, there is no expectation that an application
  package that installs a .desktop file runs any particular utility
  to update caches, because we never had a cache for this before

For what it's worth, Ryan's plan seems sound to me.

> Though at that point I'd suggest moving it to
> somewhere like /var/lib/shared-mime-info or something.

That only works for system-wide installations as root
(/usr/share/applications and perhaps, depending how the spec is worded,
/usr/local/share/applications). The search path is longer than that:
~/.local/share/applications by default, and setting XDG_DATA_HOME or
XDG_DATA_DIRS changes it per-user and perhaps even per-process.

Distributions that are uncomfortable with having files in /usr not under
direct package control could make /usr/share/applications/.metadata a
symlink to /var/lib/applications.metadata or something?

Note that the usual "what if /usr is read-only?" argument does not apply
here: if you're installing a .desktop file into /usr/share/applications,
then you've clearly made /usr read/write, even if that's only temporary.
There is plenty of precedent[1] for mutable files in /usr that are only
written during package installation, even in Debian, which is usually
one of the most pedantic distributions for that sort of thing.

    S

[1] GLib's lists of GIO modules, the MIME cache, glibc locales are among
the examples