basedir spec and plugins

Stefan.Kost at Stefan.Kost at
Tue Jun 30 01:16:50 PDT 2009


>-----Original Message-----
>From: ext Rodney Dawes [mailto:dobey.pwns at] 
>Sent: 30 June, 2009 05:45
>To: Kost Stefan (Nokia-D/Helsinki)
>Cc: xdg at
>Subject: Re: basedir spec and plugins
>On Fri, 2009-06-26 at 15:19 +0200, Stefan.Kost at 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 
>> 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.

Good point. Have not thought about shared directories. having the arch in there totaly makes sense.

>> 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.

One feature that I like about the basedir spec is that is has two vars for each type - _DIRS and _HOME. PATH would be XDG_BIN_DIRS and LD_LIBRARY_PATH would be XDG_LIB_DIRS. But then the application that wants to put something there, would need to scan the path for a path component that is under $HOME and hopefully writable.


More information about the xdg mailing list