Package: xdg-desktop-portal Version: 1.17.2-1 Severity: wishlist X-Debbugs-Cc: jeremy.bi...@canonical.com, debian-desktop@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
