Talk:General recommendations

From ArchWiki
Jump to: navigation, search

XDG Base Directory

Configuration

  • There is no XDG configuration in this guide.
So after this guide (Base+Post-Install), XDG environment variables not configured. - PiroXiline (talk) 14:08, 20 September 2016 (UTC)
This is not an issue. As pointed out below, applications must use the ~/.config and ~/.local paths when the respective variables are not set. -- Alad (talk) 08:35, 21 September 2016 (UTC)
As I also pointed out below, this is (apps not fully comply to specification) an issue to user. Yes, this is not a users fault, but we can help user to workaround some of that by providing additional info in Post-install process. Because:
User who not specified XDG envs after install, and try to have structured system, keep track of config changes, backup app configs and data; user faces problems:
  • Need to sort-out through large number of ~/.appfolders
  • Check for what of them are old duplicates of migrated to ~/.config/appfolders.
  • User doesn't know, maybe some of that old files in migrated ~/.appfolders, are still used by apps.
  • After that keep a track of where what app goes in, uses ~/.config, or ~/.appfolders or both.
  • ~/.appfolders have a mix of configs, data, cache. To make backups you need to sort that out. ~/.mozilla, ~/.kodi, ~/.x2go folders are a great examples of huge mixes of configs, appdata and caches. Not everyone wants to backup and keep track of all that cache that changes constantly. That also in many cases applies to appdata.
Moreover on Arch system, with multiple years history. That is why I propose to clarify workarounds and make them obvious while user guided through post-install process. Because later it can be too late. -- PiroXiline (talk) 13:24, 22 September 2016 (UTC)
There's some confusion here; "environment variables" may refer both to the variables defined in the XDG specification itself (XDG_CONFIG_HOME, XDG_DATA_HOME, etc.) and to variables to modify the configuration directory of non-compliant applications.
All of this is discussed in XDG Base Directory support. The other sections discuss where to best put a link, if anywhere; closing -- Alad (talk) 14:33, 22 September 2016 (UTC)

Problem, apps with $HOME/.folders, while XDG env variables empty

See above. -- Alad (talk) 08:35, 21 September 2016 (UTC)
  • Many applications not comply specification completely, having a bug. By using not default values: creating $HOME/.folders, while proper path $HOME/.config/folders must had been set inside the app.
This is a main bug from where mess of $HOME/.folders become created over time. While other applications comply XDG and store files in proper places.
The manual migration process became more tedious and complex over time. (I have 84 $HOME/.folders now). And not sure how to accomplish soft migration.
See tables at XDG_Base_Directory_support. - PiroXiline (talk) 14:08, 20 September 2016 (UTC)
It's not a bug, it's a feature that certain applications have not implemented. Having configuration files in a single folder may simplify maintenance, but it has no effect on actual functionality of an application. -- Alad (talk) 08:35, 21 September 2016 (UTC)
You are right. It is more lack of popper support of XDG Base in present, or lack in the past, which creates also a problem of live migration to proper XDG-places for developer and maintainers. -- PiroXiline (talk) 11:16, 22 September 2016 (UTC)

Solution to apps with $HOME/.folders, while XDG env variables empty

  • So explicit XDG Base Directory configuration at post-install going to solve most of these problems.
We really can not hope that every developer going to use proper XDG Base Directory values. This spec released in 2003.
For now I am not clearly familiar with XDG and all in Environment_variables#Defining_variables, what going to work in /etc/environment and how, and so on. - PiroXiline (talk) 14:08, 20 September 2016 (UTC)
I can't think of a good section to put it in. It might fit in a Backup section, at least if we had one ... -- Alad (talk) 08:35, 21 September 2016 (UTC)
I looked directly to XDG Base Directory support. This article directly named "support", which mean discussion of support in application and Arch, and directly article say at the top: "(in article) For those (apps) not currently supporting the Base Directory Specification, workarounds will be demonstrated to emulate it instead (in this article).".
So it is very logical to add there an info of how to explicitly set these variables. Basic setup on user level seems the solution. -- PiroXiline (talk) 13:42, 22 September 2016 (UTC)
To my dismay the table already includes an "export" line in every single entry. We're not going to add to that by duplicating Environment variables, which is linked twice from the article. Closing -- Alad (talk) 14:37, 22 September 2016 (UTC)

Sample the explicit XDG Base Directory environment variables setup

[Moved to Talk:XDG Base Directory support -- Alad (talk) 14:39, 22 September 2016 (UTC)

Proposition to add 'Organize user configuration' section in 'System maintenance' and make more obvious reference to 'XDG Base Directory support' and 'Dotfiles#Version control'

Of course I agree that there shouldn't be a detailed explanation here, however I think it's also true that currently it's not very easy to reach XDG Base Directory support through links from this article: I think the best path is only from a link in System maintenance#Old configuration files, which is a too specific section. What if we add a new, more explicit section in System maintenance (maybe only under System_maintenance#Tips_and_tricks?) like this:


Organize user configuration

Many applications store user-specific data, such as configuration files, inside the $HOME folder: in order to facilitate maintenance it is important to organize those files in a rational and easily-accessible way. See XDG Base Directory support for the most commonly followed standard; see Dotfiles#Version control for common helper tools.


Kynikos (talk) 14:37, 21 September 2016 (UTC)

That sounds good, but it'd be even better as part of a larger Backup section, with amongst others a link to Synchronization_and_backup_programs. -- Alad (talk) 19:42, 21 September 2016 (UTC)
But System_maintenance#Backup already links to Synchronization_and_backup_programs, or were you talking about adding a Backup section to this very article?
Instead, I propose to:
  1. Rename System_maintenance#Clean_the_filesystem to #Tidy_up_the_file_systems;
  2. Rename System_maintenance#Old_configuration_files to #Organize_configuration_files;
  3. Merge my section above into #Organize_configuration_files;
  4. Merge the link to Dotfiles#Version control inside System_maintenance#Configuration_files.
Kynikos (talk) 11:19, 22 September 2016 (UTC)