On Fri, 2009-06-26 at 15:19 +0200, [email protected] wrote: > hi, > > the spec [1] only talks about > XDG_DATA_DIRS/HOME -> e.g. icons, docs, ... equiv of e.g. /usr/share > XDG_CONFIG_DIRS/HOME -> settings, equiv of /etc > XDG_CACHE_DIRS/HOME -> e.g. a plugin cache, equiv of /var/cache > > but there is nothing for plugins (equiv of /usr/lib). E.g. the user > aquired the gstreamer mp3 decoder plugin from fluendo (which sits > right now in ~/.gstreamer-0.10/plugins). If this would justify xdg > where should t go instead? Would it make sense to add a > XDG_LIB_HOME -> $HOME/.local/lib > gstreamer could then use $XDG_LIB_HOME/gstreamer-0.10/
This would be very nice indeed. However, there is a slight problem with the scope. What about 32-bit vs. 64-bit? And what about arch-independent plug-ins? I suspect they probably shouldn't all go in the same directory, especially for systems where you might dual-boot both 32 and 64 bit OSes. However, I do agree we need a solution, since plug-ins aren't really generic data or configuration information. > Would we also want this for executables? > XDG_BIN_HOME -> $HOME/.local/bin Doesn't $PATH solve this already? I don't really see the point of adding another variable which duplicates what $PATH does. _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
