New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flatpak claims adherence to desktop standards #191

Closed
soc opened this Issue Sep 30, 2017 · 20 comments

Comments

Projects
None yet
9 participants
@soc

soc commented Sep 30, 2017

Flatpak's FAQ claims the following:

How does Flatpak relate to freedesktop.org technologies such as desktop files and appstream metadata?
These standards are incorporated as mandatory parts in the flatpak definition. By relying on these standards we are building on years of investment and support under Linux.

This doesn't seem to be true.

One of the standards Flatpak violates is the XDG base directory spec: It incorrectly places files outside of the specified XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME directories, by creating and populating a .var directory in $HOME.

I think the documentation could be improved by dropping the "freedesktop.org technologies such as ..." part, and explicitly listing both the standards adhered by Flatpak as well as those standards Flatpak chose to ignore.

I believe this could reduce user confusion as users might expect that an application formerly named xdg-app follows the same-named standard.

@TingPing

This comment has been minimized.

Member

TingPing commented Sep 30, 2017

Well the standards it mentions it uses. Another FAQ entry about ~/.var/app would make sense.

@soc

This comment has been minimized.

soc commented Sep 30, 2017

@TingPing What do you think about #192? Is this going into the right direction?

@matthiasclasen

This comment has been minimized.

Contributor

matthiasclasen commented Sep 30, 2017

No. We are not 'violating' anything.

@soc

This comment has been minimized.

soc commented Sep 30, 2017

Now I'm a bit baffled.

The spec clearly states where different files have to be placed. The Arch wiki even has a huge list of applications with associated bug reports to make them aware that dumping things into users' home folders is not the way to go anymore.

Flatpak clearly discards this and ignores the year-long efforts of reclaiming a user's home directory for the actual user, instead of it being a general dumping ground for application's private data.

Or am I misunderstanding something, and it's purely the word "violating" that should be adjusted a bit in your opinion? Would something like "does not conform to" be more to your liking?

@TingPing

This comment has been minimized.

Member

TingPing commented Sep 30, 2017

The spec says default locations that can be overridden with env vars. Flatpak overrides them in order to get portable and self contained applications.

@soc

This comment has been minimized.

soc commented Sep 30, 2017

@TingPing Which env var does Flatpak override? On my system neither XDG_CACHE_HOME, nor XDG_CONFIG_HOME nor XDG_DATA_HOME are overridden, and I would strongly object to any application doing that without my permission. Still, a .var directory is obviously created and populated.

Whatever env var Flatpak uses to decide on the location of .var, it doesn't seem to use any of the ones specified above.

@TingPing

This comment has been minimized.

Member

TingPing commented Sep 30, 2017

On my system neither XDG_CACHE_HOME, nor XDG_CONFIG_HOME nor XDG_DATA_HOME are overridden, and I would strongly object to any application doing that without my permission.

They are overriden in the sandbox not on the host.

Whatever env var Flatpak uses to decide on the location of .var, it doesn't seem to use any of the ones specified above.

Applications are sandboxed and have no access to $HOME so they get their own private directory to store things. The spec has nothing to do with this as it only defines the defaults.

@soc

This comment has been minimized.

soc commented Sep 30, 2017

I'm not talking about sandboxed applications, I'm talking about Flatpak itself. Even if all sandboxed applications decided by their own free choice to write to .var that would be an issue of Flatpak.

@matthiasclasen

This comment has been minimized.

Contributor

matthiasclasen commented Sep 30, 2017

The base dir spec is a recommendation for where desktop applications are meant to place their auxiliary files. flatpak is not a desktop application.

@matthiasclasen

This comment has been minimized.

Contributor

matthiasclasen commented Sep 30, 2017

And even so, it is not a law that says you can't touch any other place. It just makes recommendations for common types of data applications might want to save to disk.

@matthiasclasen

This comment has been minimized.

Contributor

matthiasclasen commented Sep 30, 2017

Yes, I'm mainly objecting to the term 'violate', here. Flatpak does follow the basedir spec where it makes sense, for example for the per-user repositories.

@soc

This comment has been minimized.

soc commented Sep 30, 2017

The base dir spec is a recommendation for where desktop applications are meant to place their auxiliary files. flatpak is not a desktop application.

This is incorrect (but a quite popular excuse): Autostart entries, Git, fonts, dconf settings, mesa, menu entries, Bazaar, and user directory settings are also not desktop applications, but they follow the spec.

And even so, it is not a law that says you can't touch any other place. It just makes recommendations for common types of data applications might want to save to disk.

Exactly because the spec lacks the means for proper enforcement, I would like to have it clearly documented, so that users like me can make a well-informed decision on whether to use Flatpak or not, without running into unwelcome surprises.

Yes, I'm mainly objecting to the term 'violate', here. Flatpak does follow the basedir spec where it makes sense, for example for the per-user repositories.

Isn't this a bit like running into a speed trap and trying to argue that that the ticket should be dismissed because you usually follow the speed limit "where it makes sense"?

To be clear:

I'm not trying to question your implementation choices, I just like to have the choices that have been made – as a matter of fact – to be clearly documented.

It's a matter of fact that Flatpak creates the .var directory in violation of the XDG base directory spec, and this should be clearly documented.

That's what the PR does.

@soc

This comment has been minimized.

soc commented Sep 30, 2017

I adjusted the PR and replaced "violate" with "does not adhere to", hope it is fine this way!

@Lonsfor

This comment has been minimized.

Lonsfor commented Sep 30, 2017

Maybe a better solution would be have a flatpak folder in XDG_CACHE_HOME, XDG_CONFIG_HOME and XDG_DATA_HOME with the application's data in its respective folder.

@TingPing

This comment has been minimized.

Member

TingPing commented Oct 1, 2017

@Lonsfor Applications can and do write arbitrary data outside of those directories. For example the Steam flatpak might contain a dozen subdirectories containing game data and configs from dozens of games that do their own thing.

@mjog

This comment has been minimized.

mjog commented Oct 31, 2017

A nice emergent property of the XDG spec is not only being able to back up all config files by simply archiving ~/.config, or being able to old cached files by "simply" deleting anything in ~/.cache older than n days, but also enabling software like backup apps being able to determine these locations programmatically, at runtime.

Flatpak's current behaviour breaks this, which kinda sucks. It's not as bad as being back in the bad old days of having to hunt-and-peck for these files on a per-app basis, but it does add back another location that now needs to be guessed by backup apps, etc.

@allanday

This comment has been minimized.

Collaborator

allanday commented Jan 25, 2018

I don't see anything that needs to be changed here, and the discussion has dried up, so closing.

@rokups

This comment has been minimized.

rokups commented Aug 14, 2018

A new discussion popped up on reddit discussing applications littering $HOME. Participants generally agree that littering of user's home directory is undesirable. Please reevaluate location of .var. Especially if there is no good technical reason behind having it in ~/.var as opposed to ~/.local/var. Please consider convenience of your users.

@forteller

This comment has been minimized.

forteller commented Aug 14, 2018

I'm quite flabbergasted that a project so closely related to Gnome does not adhere to the best practice of freedesktop.org. I want a clean and smooth experience when using my computer. That's why I've chosen Gnome. I thought this was the general sentiment in the Gnome community.

If there's an important reason to do it like this, then ok. But I can't seem to find any good reasons here. When so many people want you to change, to what must be said to be more "Gnome like", then it's strange that you don't consider it, or even seem to want to give us a good reason why not.

@alexlarsson

This comment has been minimized.

Member

alexlarsson commented Aug 14, 2018

The ~/.var/app location for per-application data as reached after a long discussion, including with some of the developers of the xdg basedir spec. We never got to updating the spec for this, but that will happen eventually.

@flatpak flatpak locked as resolved and limited conversation to collaborators Aug 14, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.