xdg module for common freedesktop tasks

[TingPing]

So I started on a freedesktop module that encompasses various tasks one might do and wanted some feedback on the idea and how it might be implemented.

Desktop files

• install_desktop()

  Calls desktop-file-install which validates the file and rebuilds the desktop mime cache. Alternatively we could just call update-desktop-database and install ourselves. Validation makes more sense below IMO.

• validate_desktop()

  Calls desktop-file-validate during test, this does not seem easily doable from a module?

Appstream files

• install_appstream()

  Just installs into the correct directory for you, not useful?

• validate_appstream()

  Calls appstream-util validate, see above.

Mime files

• install_mime()

  Installs mime file and calls update-mime-database for you.

Icons

• install_icons()

  Calls gtk-update-icon-cache on install.

Related to #295. As mentioned there we should probably only run these when DESTDIR is unset, is this doable from a module too?

[ignatenkobrain]

one note, that users should be able to disable all such hooks (as it slows down and can even break packaging process).

[jpakkane]

This is how Gnome-Twitch does the post install updates. The problem here is that, AFAICT, you should only call those updater functions when hard-installing to /usr, which is almost never. During package building (and Flatpak?) they should not be called, as ignateknobrain mentioned.

The real solution would be to have a daemon that watches the install dirs with inotify and does the magic when things are updated, but I'm guessing that will be a hard thing to get to the distros.

[TingPing]

Related to #295. As mentioned there we should probably only run these when DESTDIR is unset, is this doable from a module too?

Really that should cover every packaging situation I know of.

The real solution would be to have a daemon that watches the install dirs with inotify and does the magic when things are updated, but I'm guessing that will be a hard thing to get to the distros.

Any decent package manager already triggers these on installing a package automatically, but this is for when you go outside of the package manager.

[ignatenkobrain]

@TingPing, yeah we got filetriggers in RPM recently ;)

[ignatenkobrain]

about validate_*(), I think it should be done automatically during ninja test

[TingPing]

So to make progress on this what needs to happen from a module:

• Be able to extend tests
• Detect the DESTDIR at install time

I think the latter should be doable similiar to how gtkdochelper.py works so I'll look into that.

[rastersoft]

Also don't forget that if an user installs a program in its home folder, the .desktop files must be installed at $XDG_CONFIG_HOME/autostart. In case $XDG_CONFIG_HOME is not defined, the path is $HOME/.config/autostart.

[jpakkane]

What is the correct way of determining when to install to $HOME/.config/autostart? If prefix is /home/something? If prefix is not /usr/something? Does DESTDIR come into play? Like if prefix is /usr and DESTDIR is /home/username/devroot?

[rastersoft]

In AUTOVALA I use the rule:

if( ${CMAKE_INSTALL_PREFIX} MATCHES "^/home/" )

This is: if PREFIX starts with "/home/". DESTDIR should not come into play because this would never be used in packages, only when the user manually builds the program in its system and manually installs it in its user folder (useful when (s)he does not have root access).

[rastersoft]

In fact, installing something to /opt/whatever... should not install .desktop files at $HOME/.config...

[TingPing]

Autostart is an unrelated directory for... autostarting applications.

[rastersoft]

Yes, but you install there specific .desktop files, which have the "X-GNOME-Autostart-enabled=True" key.

[TingPing]

No extra key is needed: https://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html
That key must be some gnome hack that you should probably avoid for the sake of portability.

Anyway it is a different location for a different purpose. Sure a function could be added for that too though.

[nirbheek]

We might also want to provide access to the XDG_* environment variables via this module:

https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html

Sort of the equivalent of g_get_user_data_dir().

[fooishbar]

I'd request this be called xdg rather than freedesktop; xdg refers to these desktop standards and specifications, whereas freedesktop is a much wider effort.

[TingPing]

I've pushed an initial version here: https://github.com/mesonbuild/meson/tree/tingping/xdg-module

[mcatanzaro]

This would get us most of the way to eliminating post_install.py scripts in GNOME, right? (The only other missing part would be glib-compile-schemas, which belongs in the GNOME module.)

[bilelmoussaoui]

I would like to work on this, as the meson_post_install script is imo shouldn't be needed at all for that basic stuff :)
also, i think that install_desktop & install_apstream should provide an easy way to include the translations files
Something like a po karg.

I would like to know which are the steps to do that? And is this the list mentioned on the issue is all that should be implemented or something else should be added?

[TingPing]

@bil-elmoussaoui Well the work isn't the hard part I just still am not happy with the API.

i think that install_desktop & install_apstream should provide an easy way to include the translations files
Something like a po karg.

Yes that could be valuable but raises more API questions. #1757 might be relevant to that one.

[sardemff7]

For translations, a preset would fit nicely. The API could be that install_desktop and friends would return an object with a .get_i18n_files() method, that would call internally i18n.files(<files>, suffix: 'in', language: {'desktop'|'xml'}, preset: {'desktop'|'appstream'}) which you can then pass to i18n.create_pot() (as of current #1757 design).

[TingPing]

@sardemff7 We not only need to extract translations, which your idea sounds like it handles, but we need to merge files at build time too.

[sardemff7]

Sorry, missing merge: true in the i18n.files() call. However, i18n.files() + i18n.create_pot() supports installing too (just like custom_target()), so install_desktop() should rather be install_desktop_i18n() or maybe just trigger_desktop_database_update().
Is there anything that install_data() (or i18n.files() if translations are needed) cannot do if we have validate_desktop_file() and trigger_desktop_database_update()?

[TingPing]

or maybe just trigger_desktop_database_update()

I am sort of leaning in that direction, the only thing lost by that though is the detail of where things are installed.

[sardemff7]

xdg.get_appstream_dir() (and friends) so you always get the directory that the update tool will use.

[TingPing]

So another approach discussed at GUADEC for this is to just automatically do the right thing:

https://github.com/mesonbuild/meson/tree/wip/tingping/xdg-auto-post-install

Two remaining problems:

• Respect datadir (doable, need to call mesonintrospect)
• Fix handling gettext, or any, module that installs its own files, seems not trivial

[hbons]

@TingPing how's this going? I'd love to use this. Let me know if you need testers.

[TingPing]

Depends upon #1601 getting fixed.

[tristan957]

@TingPing seems like support now exists for #1601, at least the i18n module uses it according to @eli-schwartz

[eli-schwartz]

It's not really that "support now exists".

It's a matter of architectural design. It used to be quite common for modules to make everything into custom meson.add_install_script() dispatched functionality instead of returning a custom_target(..., install: true) (or perhaps returning an install_data() in this case).

On the other hand, we've since added https://mesonbuild.com/Gnome-module.html#gnomepost_install for running things like gtk_update_icon_cache. I guess in theory we could move it to a new module... personally I've never seen the point of a special module function that just does install_data but specialized for a specific type of file and a pre-set install_dir.