Skip to content
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

Please support XDG base directory specification #994

Open
shmerl opened this issue Aug 26, 2024 · 5 comments
Open

Please support XDG base directory specification #994

shmerl opened this issue Aug 26, 2024 · 5 comments
Assignees

Comments

@shmerl
Copy link

shmerl commented Aug 26, 2024

Currently on Linux libgphoto creates $HOME/.gphoto directory when used. Please use XDG base directory specification to avoid cluttering $HOME.

@shmerl
Copy link
Author

shmerl commented Aug 26, 2024

Looks like a dup of this bug, so I'll close this.

@shmerl shmerl closed this as completed Aug 26, 2024
@shmerl shmerl reopened this Aug 26, 2024
@shmerl
Copy link
Author

shmerl commented Aug 26, 2024

Hm, on the other hand that's for the library, so may be it needs a separate one. So let's keep it open.

For me the problem occurs when using gwenview which relies on libgphoto2.

@ndim
Copy link
Member

ndim commented Sep 5, 2024

This is definitely an issue for the libgphoto2 library.

@ndim
Copy link
Member

ndim commented Sep 5, 2024

Trying to develop a way to achieve this.

The libgphoto2 code could, instead of just using ~/.gphoto

  • If XDG_CONFIG_HOME is not set, treat it as $HOME/.config for the following steps.
  • Try $XDG_CONFIG_HOME/gphoto/. If present, use it.
  • Otherwise, look for ~/.gphoto/.
    • If present, make sure the XDG based parent directories exist, creating directories as needed, then rename(2) ~/.gphoto/ to $XDG_CONFIG_HOME/gphoto/. Be aware of symlink attacks and similar things.
    • Otherwise, create XDG_CONFIG_HOME/gphoto/. Be aware of symlink attacks and similar things.
  • Use $XDG_CONFIG_HOME/gphoto/.

This would ensure migration to the new location.

What should happen if someone uses an older version of libgphoto2 which looks in ~/.gphoto/ after having used a version of libgphoto2 which moved ~/.gphoto/ to $XDG_CONFIG_HOME/gphoto/? It would then generate a new ~/.gphoto/ directory and generate a new ~/.gphoto/settings file with defaults.

To solve that, the new libgphoto2 could, after having moved ~/.gphoto/ to $XDG_CONFIG_HOME/gphoto/, create a symlink ~/.gphoto pointing $XDG_CONFIG_HOME/gphoto to let older libgphoto2 versions use the new directory. Then at some time in the future (say, in a year or two), libgphoto2 could change to remove the ~/.gphoto symlink (if it still points to $XDG_CONFIG_HOME/gphoto, of course).

This strategy should obviously apply on Linux, BSD, ...

Should it also apply on MacOS? Possibly.

And on Windows? Probably not. Right?

@ndim ndim self-assigned this Sep 5, 2024
@shmerl
Copy link
Author

shmerl commented Sep 5, 2024

Not exactly. If $XDG_CONFIG_HOME is defined - then use $XDG_CONFIG_HOME/gphoto (create it if it doesn't exist).

If it's not defined use $HOME/.config/gphoto (create it if it doesn't exist).

Plus before creating (if selected location doesn't exist) use that check for fallback you mentioned if you want to keep some backwards compatibility for a while.

I don't think you need to overcomplicate things with renaming and etc. Just support fallback for a while and then remove legacy path in the code completely (after a year or however long you decide).

It doesn't need to apply to macos and Windows, they don't follow XDG specification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants