Detect when running inside a flatpak sandbox

[cpba]

This change detects when dolphin is running inside a flatpak sandbox and ensures xdg directories are used.

Running in flatpak requires adhering to the xdg spec because other paths aren't guaranteed to be accessible. Doing otherwise leads to errors when eg. the configuration file is readable but not writeable, among other possible cases.

[AdmiralCurtiss]

Is checking for existence of /.flatpak-info the canonical way to detect whether one is inside a flatpak or not?

[delroth]

I don't see why the behavior should be different. The change you're introducing means that running Dolphin on the same system might end up with two different sets of configurations, game saves, etc.

Flatpak showing the directories but not having them writable sounds like a bug in your sandboxing that we shouldn't have to introduce special cases to work around.

[cpba]

Is checking for existence of /.flatpak-info the canonical way to detect whether one is inside a flatpak or not?

Yes, it is the canonical way.

Flatpak maintains this file inside the sandbox and it doesn't exist outside, it is used to display various information about the current sandbox such as its id, its runtime, or the flatpak version among many others.

[cpba]

The change you're introducing means that running Dolphin on the same system might end up with two different sets of configurations, game saves, etc.

Keep in mind that this could (and already does) happen regardless of this change. The objective of this merge request is to make the behaviour more consistent and minimise the chances that users end up hitting edge cases.

Flatpak showing the directories but not having them writable sounds like a bug in your sandboxing that we shouldn't have to introduce special cases to work around.

It works in the same way that other sandboxed platforms already work (eg. android), configuration files must go in a single canonical path because the user is able to allow/deny access to the rest of the filesystem. Flatpak is just more granular, and reuses the existing xdg spec that dolphin already supports in order to achieve it.

[cpba]

Could somebody please help me make sense of what I'm seeing in the ci?

Is the android build expected to fail? This change is very minimal and doesn't touch anything on the android code paths. Is it failing because of something unrelated?

What should I be looking for in the behaviour differences, is there a reason why all the problems are constrained to uberogl-lin-radeon?

Sorry if these questions are elemental, it's my first time contributing to this project and I'm still a bit lost.

[JosJuice]

I think both of those problems are because of something unrelated. Try rebasing your pull request on the latest version of master.

There is a reason behind what's happening behind uberogl-lin-radeon, but it's kind of a long story and has nothing to do with your PR. Some details are available at https://github.com/dolphin-emu/fifoci/pull/48.

[cpba]

Thank you, that was very helpful.

I have rebased my pull request on latest master, can I rerun the ci now, or can it only be done by somebody with commit rights?

[JosJuice]

Rerunning it requires a right which is handed out to more people than commit rights are, but which you don't have. I've reran it for you.

[cpba]

Thank you, all the tests came out great this time.

[cpba]

I have made the modifications suggested in the review and rebased on current master.

However I don't have permission to rerun the ci, could somebody please do it for me?