After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 523057 - [Tracking bug:] Match FreeDesktop directory specs
[Tracking bug:] Match FreeDesktop directory specs
Status: RESOLVED OBSOLETE
Product: general
Classification: Other
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Unknown User
Unknown User
: 588281 (view as bug list)
Depends on: 164123 166643 304147 328679 335547 405913 426391 447840 459338 480026 494007 504033 509475 517717 518585 518589 518590 518594 518596 518597 518598 518724 519408 519425 520103 520398 522619 522806 522810 522811 522812 522813 522817 522844 522845 522848 522849 522851 523038 523174 524304 533199 536111 544053 557634 560092 561438 563665 569825 575906 579359 583210 592370 593863 594217 596108 596173 598102 601476 613643 613644 614030 617555 627939 631427 631596 641115 641354 646389 646390 646391 646393 646394 646507 646508 646510 646512 646584 646631 646644 646663 659104 674873 674874 674875 674884 675316 675391 675401 675410 689419 753967
Blocks:
 
 
Reported: 2008-03-17 21:13 UTC by André Klapper
Modified: 2020-11-24 10:15 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description André Klapper 2008-03-17 21:13:44 UTC
tracking bug.
Comment 1 Vincent Untz 2008-03-18 09:16:13 UTC
I'm going to say this here instead of in tons of bugs.

Before we start moving all kind of stuff from ~/.gnome2/ to ~/.config/, we need to discuss this. This causes migration problems, compatibility problems, etc. We have to be careful.
Comment 2 Lionel Dricot 2008-03-18 10:00:50 UTC
Vuntz : but what about the principle ? Do we agree that moving to $XDG_* is a good idea and necessary ? (I think so but I don't know if it's a consensus)

If yes, then of course there are a lof of problem but most applications will handle it theirselves. (It might be tricky for some other) In other words : it's then only a technical problem. 

Also, I want to insist that this is *not* about putting .gnome2/* in .config. It's a lot more subtle than that and it's about well separating user data and user preferences. I think it's really important to insist on it because if not understood perfectly, it will not solve anything. Only one application that doesn't understand this and put data in .config and all the process is broken. (You have to think all the time that .config could be deleted completely at any time in order to restore the default preferences. That's unlike .local)
Comment 3 Vincent Untz 2008-03-18 10:20:31 UTC
(In reply to comment #2)
> Vuntz : but what about the principle ? Do we agree that moving to $XDG_* is a
> good idea and necessary ? (I think so but I don't know if it's a consensus)

I'd blindly agree with moving to the $XDG dir if we didn't have something in place at this point. Right now, I don't know. At least, I know it's not necessary;

> If yes, then of course there are a lof of problem but most applications will
> handle it theirselves. (It might be tricky for some other) In other words :
> it's then only a technical problem. 

No. We should agree on the way to handle this globally and then implement this in all modules.

> Also, I want to insist that this is *not* about putting .gnome2/* in .config.
> It's a lot more subtle than that and it's about well separating user data and
> user preferences. I think it's really important to insist on it because if not
> understood perfectly, it will not solve anything. Only one application that
> doesn't understand this and put data in .config and all the process is broken.
> (You have to think all the time that .config could be deleted completely at any
> time in order to restore the default preferences. That's unlike .local)

Well, to be honest, given the opened bugs, I guess most people will just move from .gnome2 to .config without even thinking what's a setting and what's not a setting... It clearly needs thoughts, and the bugs are not enough for this, unfortunately.
Comment 4 Lionel Dricot 2008-03-18 14:47:25 UTC
Given what I saw in other bugs (like proposed patches), I agree that the issue needs now more debate, explanations and guidelines.

It was proposed to make this a "Gnome goal" which could help. What do you think ?
Comment 5 Vincent Untz 2008-03-19 14:27:47 UTC
Yes, it would make sense to have a GNOME Goal for this.
Comment 6 Lionel Dricot 2008-03-27 19:21:07 UTC
I've created the corresponding Gnome Goal page :
http://live.gnome.org/GnomeGoals/XDGConfigFolders

I think that the main point of discussion will be "And what about Gconf ?" 

But it's an interesting discussion.
Comment 7 Pavel Šefránek 2008-07-31 09:57:57 UTC
What about that GnomeGoal? Maybe we should make it a little more official.
Comment 8 Vincent Untz 2008-07-31 10:03:02 UTC
(In reply to comment #7)
> What about that GnomeGoal? Maybe we should make it a little more official.

I didn't see any discussion on the problems this might cause (see my comments here). So it's not going to be an official goal without this...
Comment 9 Lionel Dricot 2008-09-15 10:04:27 UTC
I tried to launch the discussion on gnome-love. I tried to send it to gnome-hackers and I'm awaiting moderation.

http://mail.gnome.org/archives/gnome-love/2008-September/msg00000.html

I suggest that people on gnome-hackers who are interested already start the discussion.
Comment 10 Javier Jardón (IRC: jjardon) 2009-07-10 21:40:56 UTC
*** Bug 588281 has been marked as a duplicate of this bug. ***
Comment 11 antistress 2009-07-24 16:20:37 UTC
Also depends on FreeDesktop Bugzilla – Bug 20411 fontconfig doesn't match FreeDesktop directories
Comment 12 Jean-François Fortin Tam 2010-05-03 18:13:31 UTC
Could this be a goal for GNOME 3.0? Has there been discussion on this [other than on this bug]?
Comment 13 Sebastian 2010-08-29 21:05:22 UTC
Hi,

I'd really love to see this implemented. It would particularly suit to make it a gnome 3.0 goal, so we start with some cleaned up config/data/cache directories when gnome 3 is ready.

Personally the messed up home directory has always been an annoyance for me ever since migrating from Windows to Linux. On windows this has been solved long ago with the introduction of "Application Data" and "Local Settings" etc which are hidden in the profile folder. Also not all applications make right use of it, it still makes many things easier in windows.

Just my opinion
Cheers

P.S. In addition to the FreeDesktop spec I think is also necessary to remember that applications don't save the default settings into the .config folder. Instead only those options should actively be saved that differ from the default settings -- this would help to keep the .config folder clean.
Comment 14 Olav Vitters 2010-08-29 21:30:44 UTC
sbastig@gmx.net: The intention is to implement this (no ETA though). If you can help write patches or can find people who can contribute patches to fix this the various GNOME maintainers would really appreciate the assistance.
Comment 15 Sebastian 2010-08-30 11:58:48 UTC
@Olav,

the way I understand this is, that this is currently not an approved gnome goal. 
In http://live.gnome.org/GnomeGoals/XDGConfigFolders the message is:
"This should not be applied before being officially turned into a GNOME Goal."

And the bottom line of this bug is: "Dont implement until we approve it as a gnome goal and made sure migration goes smooth.".

So far I have already written 3 patches for (tilda, eog and update-notifier), and plan to write more as I find time. But for example the bug for eog (bug 522806) is blocked by this bug. I would love to write more XDG patches if I could be sure there is a general willingness to merge them, this is why I suggest to make this an official gnome goal for 3.0

There is also another guy who has been writing patches (Christian Klein):
https://bugzilla.gnome.org/show_bug.cgi?id=627939.

So lets mark this bug as confirmed and start discussing about whether or not we make this a gnome 3 goal. I don't think we are short of people who write patches.

Cheers
Sebastian
Comment 16 André Klapper 2010-08-30 12:07:25 UTC
(In reply to comment #15)
> this is currently not an approved gnome goal. 

There is no defined way how to "approve" anyway hence I wouldn't care... :)

> But for example the bug for eog (bug 522806) is blocked by this bug.

No, it is the other way round.

> I would love to write more XDG patches

It is definitely very welcome!
Comment 17 Sebastian 2010-08-30 12:38:50 UTC
So how did the other gnome goal get turned into official goals? Is this done during some conference? Or via one of the mailing lists? Could you point me to some more information?

>No, it is the other way round.
Ah ok, then I mixed that up.
Comment 18 Olav Vitters 2010-08-30 13:01:31 UTC
André: Approving stuff is a task of the release team.

So:
1. Discuss on desktop-devel-list. Though IIRC there has been some discussion. Best when sending a new msg to summarize the existing stuff.
2. Have decision taken by release-team. #2 really depends on a good discussion at step 1

Note:
* How to migrate from old location to new?
* How long to check if stuff needs migrating?
* XDG means more locations to store things instead of current usage
Comment 19 Sebastian 2010-08-30 15:33:53 UTC
I have just taken some time to sum up briefly what I could find on different pages, and also created a resources section with the different links. Maybe we can take this as a starting point for discussion about what needs to be done and how?

Whats more I just skimmed thorugh a couple of bugs and found many comments where people write something like this:
[...] I'd like to first have this GNOME Goal "approved" by community
before fixing this bug. [...] (from eog)

--------------------------------------------------------------------------------
* XDG means more locations to store things instead of current usage!
The old configuration files are currently stored directly in the home folder such as "~/.<programname>", the XDG spec proposes to move the files stored in this folder to three different folders based on the type and content of the files. These three folders are ".cache/", ".config/" and ".local/share/" the reasoning behind these three folders is that .cache only contains temporary data which can automatically be regenerated by a program, thus deleting it would have no consequences to the user other than making the program slower (until the files have be regenerated). The .config folder should contain files that store the preference of the user, that is all settings for which the user has chosen a value other than the default value, deleting these files would cause the application to return to the factory setting and allow the user to enter a new set of preferences. Finally the .local/share directory should contain all the data that is unique to the user. This could be instant messaging histories, playlists, emails, temporary backups (such as opened documents) etc.

* How long to check if stuff needs migrating?

The time to check if an application needs migrating is usually very quick, just clone the repository to a local folder
~$ git clone git.gnome.org/<projectname>
~$ cd <projectname>
Then use grep to test for common code samples that are used to save stuff in the home directory such as:
projectname$ grep -R g_get_ * 
(FIXME: what are there others strings to search for?)

If you have the application installed and used it already the it might be sufficient to just check in your home folder if it created any config files.

* How to migrate from old location to new?

This usually needs some individual considerations. But mainly it includes the following steps (might be incomplete):
* Find the code places which need to be changed (see above)
* Consider into which XDG folder the files need to be saved
	* XDG_DATA_HOME
	* XDG_CONFIG_HOME
	* XDG_CACHE_HOME
* Change the code to store (and load) the files to the respective location
* Write a migration handler which checks if old files are present and migrates them to the new location.
* What about that migration handler?
* The part with the migration handler might be a bit tricky. First the old folder contains the files of all three categories, thus the migration function must need to take care to move each file and folder to one of the three categories.
* Second the migration handler needs to check if there are already some files in the new location which might get overridden and then takes steps to prevent this. Depending on the complexity and importance of the files, these steps might vary between printing a short message to stderr or display a dialog on the GUI.
* Resources?
	* The bug which discusses the gnome goal:
		https://bugzilla.gnome.org/show_bug.cgi?id=523057 
	* The GNOME Goal proposal:
		http://live.gnome.org/GnomeGoals/XDGConfigFolders
	* A blog entry about the XDG Spec:
		http://ploum.frimouvy.org/?184-cleaning-user-preferences-keeping-user-data
		http://ploum.frimouvy.org/?207-modify-your-application-to-use-xdg-folders (more detailed)
	* Ubuntu Brainstorm
		http://brainstorm.ubuntu.com/idea/1210/ (current)
		http://brainstorm.ubuntu.com/idea/6557/ (duplicate)
		http://brainstorm.ubuntu.com/idea/9343/ (duplicate)
	* The _official_ FreeDesktop specification
		http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html
	* Thoughs of other people
		http://www.aigarius.com/blog/2007/01/10/fhs-extension-for-user-home-folders/
* Show me the Code!
Some common functions to use are:
g_get_user_config_dir()
g_get_user_data_dir()
g_get_user_cache_dir()
these functions are commonly used to replace g_get_home_dir(), which simply returns the home directory.
g_build_filename()
g_mkdir()
g_rename()
g_file_test()
Use "devhelp" from the devhelp-package!
Warning: Dont just blindly replace "g_get_home_dir()" with any of the the three g_get_user_*_dir() functions and hope it will work.
FIXME: add some code samples which illustrate how to do this.
Comment 20 Olav Vitters 2010-08-30 20:07:32 UTC
(In reply to comment #19)
> * How long to check if stuff needs migrating?

I meant: Applications MUST migrate their files from ~/.$project and ~/.gnome2/$project to the XDG specs. However, how long should applications keep code to migrate from the old location to the new location? Whole of GNOME 3.x?
There is a lot of focus on startup speed. We don't want to slow down application startup for something like a migration for too long.
Comment 21 Sebastian 2011-05-24 22:47:16 UTC
The code would have to be kept until the last distribution with an upgrade path to a new version reaches EOL. So for ubuntu or debian this would be around 2 years. For example if the last ubuntu lts version still ships an application without the migration code included and the migration code is added shortly afterwards, then it should be kept until the next version ob ubuntu LTS is released. The reasoning is that you can only upgrade from one LTS version to another and not skip one, thus afterwards its no longer necessary to maintain the upgrade code.
Comment 22 Sebastian 2012-02-07 16:06:01 UTC
Please add bgo#659104 to the list of depending bugs.
Comment 23 Sebastian 2012-02-11 22:18:19 UTC
There are currently 81 bugs being tracked by this bug out of which more than two thirds are already fixed and of the remaining 25 may are being worked on currently.

Yet this tracking bug still has the status new and also the goal for this bug is only a 'next goal candidate'. When are we going to make this an official gnome goal? I believe this would give some incentive to the developers to fix the remaining bugs so that we can finally close this bug maybe with Gnome 3.6 or 3.8?

So are we going to mark this bug as confirmed?
Comment 24 Vincent Untz 2012-02-12 09:23:27 UTC
(In reply to comment #23)
> So are we going to mark this bug as confirmed?

There is no such state in our bugzilla :-) It's marked as NEW, which is pretty much the same as what you're asking for.
Comment 25 antistress 2014-04-13 19:20:58 UTC
Hi,

Great progress have been made !

What about the /home/.dbus directory : is it still needed ?

Thanks
Comment 26 André Klapper 2020-11-24 10:15:50 UTC
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all
older tickets in GNOME Bugzilla.

If this is still a valid request in a recent and currently supported version of GNOME, then please feel free to use https://gitlab.gnome.org/groups/GNOME/-/issues and/or (if this ticket is about a general Initiative) check the `9. Initiative` labels on https://gitlab.gnome.org/groups/GNOME/-/labels if they should be applied on codebase-specific tickets in GitLab. Thanks.