MPRIS name for media player snap

snapcraft
1

I’ve been trying to update the Google Play Music Desktop Player snap. I’ve managed to get everything building again (yay!), but somehow the MPRIS support fails with AppArmor denials unless I manually specify the name in the slot, like so

apps:
  google-play-music-desktop-player:
    command: desktop-launch google-play-music-desktop-player
    environment:
      TMPDIR: $XDG_RUNTIME_DIR
    desktop: usr/share/applications/google-play-music-desktop-player.desktop
    extensions:
      - gnome-3-28
    plugs:
      - unity7
      - alsa
      - audio-playback
      - pulseaudio
      - opengl
      - browser-support
      - network
      - network-bind
      - gsettings
      - avahi-observe
    slots:
      - mpris-player

slots:
  mpris-player:
    interface: mpris
    name: google_play_music_desktop_player

This used to work without the manual specification of the slot, and manually specifying the slot means that it needs to go through review. Is there something that has changed in the handling of the mpris interface? Is there something I can do to not need to manually specify the name?

2

@zyga-snapd and/or @jdstrand could provide some insight on any changes that might have happened since you last published (or installed) the last version of your snap.

3

I just had a look at the code and the name of the slot will implicitly be the same as snap name. It just happens to be that the snap name has dashes and the attribute name has underscores.

Looking at file history I don’t see any changes related to the name.

4

It looks like the upstream repo changed it’s mpris name from dashes to underscores:

https://github.com/MarshallOfSound/Google-Play-Music-Desktop-Player-UNOFFICIAL-/commit/97ac1b193a0a3d177d17c1ff556c18dc32aa2e14#diff-b29bb8523d0b5affa2959fee0f6c43de

(see the first hunk changing src/main/features/linux/mprisService.js)

So previously the app’s MPRIS name matched the snap name, and now it doesn’t. So the change to the slot declaration is correct and necessary.

1 Like
5

Hm. I wonder why they made that change? As far as I can tell, ‘-’ is a valid character in mpris names.

Although, having a poke through to the relevant bit of the DBus spec it says:

Note that the hyphen (’-’) character is allowed in bus names but not in interface names. It is also problematic or not allowed in various specifications and APIs that refer to D-Bus, such as Flatpak application IDs, the DBusActivatable interface in the Desktop Entry Specification, and the convention that an application’s “main” interface and object path resemble its bus name. To avoid situations that require special-case handling, it is recommended that new D-Bus names consistently replace hyphens with underscores.

Perhaps the mpris interface should allow both $SNAP_NAME and $SNAP_NAME with hyphens replaced with underscores?

1 Like
6

I like this idea. If @jdstrand agrees I will send a patch implementing it.

2 Likes
7

It is easy enough to issue a snap declaration and I’ll do that now. Thanks to everyone for the investigation. As for changing to allowing ‘’, I’d prefer not at this time because parallel installs use '’ as a delimiter which complicates the reasoning between the foo-player snap that is allowed to use foo_player and the foo snap with parallel install of player that is not (if/when we ever have a clear design for dbus and parallel installs, we could revisit this, but without that design, it feels premature to assume ‘_’ is ok).

1 Like
8

@RAOF - I’ve done this. Feel free to request a manual review or upload a new revision and it should pass automated review.