GNOME Bugzilla – Bug 518597
[0.11] Get rid of .gstreamer-X.X folder and follow fd.o xdg base directory specifications
Last modified: 2011-05-03 07:57:36 UTC
GStreamer shouldn't create a .gstreamer-X.X folder. According to fd.o specification, it should put user preferences in $XDG_CONFIG_HOME. Any user date should go to $XDG_DATA_HOME. Any cache stuffs should go to $XDG_CACHE_HOME. I believe that the registry file belongs to this particular folder. More infos : http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html The reason why I'm reporting this bug : http://ploum.frimouvy.org/?184-cleaning-user-preferences-keeping-user-data
In general I agree with you but changing this now could cause some problems. First of all, we need to check both directories for user plugins. Then, for the registry, it's not problem to use the $XDG_CACHE_HOME in general but I guess there might be some apps or scripts out there that except the registry to be at that place (and that it is the XML registry, etc...). IMHO we can ignore the last aspect and simply searching in both directories for the user plugins is no problem though, what do others think?
So let's summarize: $XDG_DATA_HOME/gstreamer-0.10/plugins for the user plugins, i.e. g_get_user_data_dir() which is available since glib 2.6 fortunately. $XDG_CACHE_HOME/gstreamer-0.10 for the registry, i.e. g_get_user_cache_dir() which is available since glib 2.6 fortunately. I'll prepare a patch for this later and attach it here...
Personally, I think moving the directory is a 0.11 change. I have no idea what scripts in the wild might have $HOME/.gstreamer-0.10 hard-coded into them, but I bet there are some.
Ok, let's postpone this to 0.11 then.
*** Bug 544053 has been marked as a duplicate of this bug. ***
I woul say that the format and location of the registry is totaly gstreamer internal. Already switching to binary format would have broken those 'tools' and I've heard of none. Searching one more location for plugins is not that bad.
It already bothers me that we switched to the binary registry and left behind 700KB xml files that noone will ever clean up, and that we can't easily automatically delete in case the user is sharing a home directory to systems that have older GStreamer installs and they actually want both. Your point that it any hypothetical tools in the wild possibly already broke when we made the binary registry the default is valid - although I don't agree with the 'would'. I could make a tool that relies on $HOME/.gstreamer-0.10/ or $HOME/.gstreamer-0.10/registry-* and it'd work with both. It seems like a pretty gratuitous change to make in 0.10 to me.
Just for the sake of the argument, you can do all kind of things like copying private headers etc.. So I don't buy the relying-on $HOME/.gstreamer-0.10/registry-* argument. I actually wonder why we can't remove the xml one. If the binary one is used, the xml is not up-to-date - a tool using this would simply not work properly. The left-over files is a valid point though and it sucks a bit. For long term users that went thru several system upgrades decrufting is not easy. On the other hand that has to happen in order to make progress. The new layout would underline that the registry is a cache file and help with various things (what to backup, better performance on live-cds, ...). I know there is worse problems, so lets see what others think about this too.
I don't understand what you're saying about private headers. The situation where deleting the old xml file is where the home directory is being shared on NFS and the people log in on systems with different GStreamer installs. Those people would have had trouble with registry thrashing and loading all the plugins every login anyway though, so forget I mentioned it. I think it's worth switching over. My inclination is to leave it until 0.11, but I really don't care much.
I strongly favor waiting until 0.11. Doing it as part of an ABI change does not require a migration strategy. A migration strategy requires planning and effort which could be better spent elsewhere.
I also think we should wait until 0.11 with this.
We also could a) use the XDG-dirs as secondary ones and switch them to default in 0.11 b) make it a configure option (e.g. for some systems without legacy) We now got Bug #546010 filed and I would like to avoid adding work-arounds.
I missed the last comment and was just about to suggest a configure option. I'd be happy with ./configure --enable-xdg-dirs that was off by default and switched in 0.11.
*** Bug 573656 has been marked as a duplicate of this bug. ***
is this enhancement still on 0.11 roadmap ? thanks
Yes, but work on 0.11 hasn't really started yet
(In reply to comment #15) > is this enhancement still on 0.11 roadmap ? > > thanks The plan is that someone makes a patch where this behaviour can be enabled in configure (--enable-xdg-dirs) (see comment #13). Then it can be tested and we can safely switch for 0.11. We still need to figure where we shall put the "plugins" subdir. See discussion on xdg-list: http://lists.freedesktop.org/archives/xdg/2009-June/010657.html (http://www.google.com/search?sitesearch=lists.freedesktop.org%2Farchives%2Fxdg%2F&q=basedir+spec+and+plugins)
question related to this: Where would we put presets (and encoding profiles) according to that scheme ? The mailing thread in comment #17 doesn't seem to have an answer for that (although things might have changed since then).
(In reply to comment #18) > question related to this: Where would we put presets (and encoding profiles) > according to that scheme ? Those are easy; below g_get_user_data_dir() > > The mailing thread in comment #17 doesn't seem to have an answer for that > (although things might have changed since then). The missing part is where to put plugins. Most installations have a $HOME/.local and e.g. g_get_user_data_dir() would then return $HOME/.local/share. But there is nothing that would return $HOME/.local/lib especially taking multi-arch considerations and network mounted homedirs into account.
Thus, without solving the lib issue the only benefit we would get is having the registry (and ev. the profile cache) in cache dir and therefore skipping it from e.g. backups.
Here's a proposed patch for 0.11 http://git.igalia.com/cgi-bin/gitweb.cgi?p=user/pnormand/gstreamer.git;a=commitdiff;h=e53507296ed06ee706131007d431eab18732fbfe It could be merged in 0.10 too but the default value of the new option should false :)
This looks quite good to me. The plugin-dir is still not arch independent but its not right now. Could you please attach patches? I would then pushes them to 0.10 after the freeze. We could also push then to 0.11 without the configure switch and #ifdefs. Until that people can object if they want :)
I'm a bit concerned about changing the location of presets for 0.10, we'd need migration code to move existing ones.
Let's just not change anything in 0.10 please.
(In reply to comment #24) > Let's just not change anything in 0.10 please. yes, let's just change this in 0.11, it's not like this is urgent and something doesn't work...
Created attachment 186480 [details] [review] core: store presets, registry and plugins in XDG directories. Presets and plugins moved to $XDG_DATA_HOME/gstreamer-0.11/ root directory. Registry moved to $XDG_CACHE_HOME/gstreamer-0.11/. Fixes bug #518597.
Comment on attachment 186480 [details] [review] core: store presets, registry and plugins in XDG directories. Looks good but can you add something about this to docs/random/porting-to-0.11.txt and also prepare patches for the other modules that install presets?
Created attachment 186872 [details] [review] core: store presets, registry and plugins in XDG directories. Presets and plugins moved to $XDG_DATA_HOME/gstreamer-0.11/ root directory. Registry moved to $XDG_CACHE_HOME/gstreamer-0.11/. Fixes bug #518597.
Seems like only -base and -bad require patching for the presets location. Preparing patches now :)
Created attachment 186876 [details] [review] base: presets moved from $HOME/.gstreamer-0.11 to $HOME/.local/share/gstreamer-0.11
Created attachment 186877 [details] [review] dvb: moved dvb-channels.conf to $XDG_CACHE_HOME
Comment on attachment 186877 [details] [review] dvb: moved dvb-channels.conf to $XDG_CACHE_HOME IMHO this should be g_get_user_config_dir() instead
commit 4e36f93924cf984d7ff1ab28e290ab9893464ad2 Author: Philippe Normand <pnormand@igalia.com> Date: Fri Apr 29 13:43:07 2011 +0200 core: store presets, registry and plugins in XDG directories. Presets and plugins moved to $XDG_DATA_HOME/gstreamer-0.11/ root directory. Registry moved to $XDG_CACHE_HOME/gstreamer-0.11/. Fixes bug #518597. commit 081202b9d3e09e315029a6546cca0298b211b8f3 Author: Philippe Normand <pnormand@igalia.com> Date: Fri Apr 29 14:14:53 2011 +0200 base: presets moved from $HOME/.gstreamer-0.11 to $HOME/.local/share/gstreamer-0.11
commit 6acbe1894374a51954b6cebd31d74c515d23ea17 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Tue May 3 09:55:48 2011 +0200 dvb: Use the user config dir instead of the cache dir for the channels configuration commit 27c761f43be7511830f707862c5c511a7467ccf7 Author: Philippe Normand <pnormand@igalia.com> Date: Fri Apr 29 14:37:04 2011 +0200 dvb: moved dvb-channels.conf to $XDG_CACHE_HOME