[Pkg-utopia-maintainers] Bug#1051996: xdg-desktop-portal: Rethink xdg-desktop-portal-backend virtual package now that we have 1.17.x

[Simon McVittie]

Package: xdg-desktop-portal
Version: 1.17.2-1
Severity: wishlist
X-Debbugs-Cc: jeremy.bicha at canonical.com, debian-desktop at lists.debian.org

See https://lists.debian.org/debian-devel/2023/08/msg00311.html for more
context about what x-d-p is, what it's for, and how it is now set up.

At the moment we have this dependency structure:

- Each desktop-specific x-d-p backend Provides x-d-p-backend
  (some are versioned Provides, but it's not clear that it makes much sense
  to do so, because what the versioning means isn't really defined)
- Backends (x-d-p-gtk, -gnome, -kde, etc.) have Depends on a suitable
  version of x-d-p
- x-d-p intentionally does not have a Depends or Recommends on a backend,
  because if it did, that would be a circular dependency (#915117)
- Packages that need working portals (Flatpak, Snap, WebKit, Steam, etc.)
  have Depends or Recommends on x-d-p and x-d-p-gtk | x-d-p-backend
- Well-integrated desktop environments have Depends or Recommends on their
  own preferred portal backends, optionally with x-d-p-backend as secondary,
  e.g. gnome-session Depends: x-d-p-gnome | x-d-p-backend
- Non-integrated or assemble-it-yourself desktop environments have no
  particular dependencies

Now that xdg-desktop-portal 1.17.x has portals.conf(5), we should probably
re-think this.

It's not clear to me whether x-d-p-backend necessarily makes sense as a
virtual package in its current form. Historically, we had a small number
of implementations (basically -gtk and -kde) each of which implemented
"most" of the possible interfaces listed in
https://docs.flatpak.org/en/latest/portal-api-reference.html.

We're starting to see a lot more backend implementations. This is good:
it makes it more likely that the user will get working portals in their
desktop environment. However, increasingly many of the backends only
implement a few interfaces: for example x-d-p-lxqt only implements
FileChooser, and x-d-p-xapp only implements a small number of interfaces
like Lockdown, Screenshot and Wallpaper (but notably, *not* FileChooser).
They both have Provides on x-d-p-backend, but neither is enough on its own
to provide enough portals to make Flatpak apps work as intended.

Perhaps we should do something like this instead?

- Well-integrated desktop environments have a $DESKTOP-portals.conf and a
  Depends/Recommends on the backends that it asks for; if they do, then
  they may also add Provides on x-d-p-config
- New real or virtual package x-d-p-fallback that arranges for a fallback
  portal backend (in practice it will be -gtk) to be used for
  non-integrated or assemble-it-yourself desktop environments
- Packages that need working portals (Flatpak, etc.) should have
  Depends/Recommends on x-d-p and x-d-p-fallback | x-d-p-config
- The x-d-p-backend virtual package eventually disappears as not
  practically useful any more

The result would be that if there is at least one fully-integrated desktop
environment installed, then the user gets its preferred portal backends,
whatever they are; or if there are no fully-integrated desktop environments
(only i3 or fvwm or whatever), then they get a fallback to x-d-p-gtk.

Thoughts?

    smcv