basedir spec and plugins
thiago at kde.org
Tue Jun 30 00:08:26 PDT 2009
Rodney Dawes wrote:
>> 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.
According to the FHS, arch-independent files go into /usr/share, as opposed
to /usr/lib. That would put it squarely inside XDG_DATA_DIRS, so the $HOME
equivalent would be XDG_DATA_HOME. So I don't think we have to worry about
Now, thinking about arch-independent plugins (which I tend to think more
of like "application scripts"), I think I finally see why there would be a
need for arch-dependent plugins. Mind you, I don't think I've ever seen
this technique used, but I can appreciate now the use-case.
So we get to Rodney's question: consider a $HOME dir shared via NFS among
many different architectures. How do you keep those multiple architectures
of the plugins in the same place?
We'll need an architecture key, which is composed by the host OS plus at
least the processor main type. In some architectures, more will be
required, like the word size (for example, binaries on Itanium can be 32-
bit or 64-bit, little endian or big endian, though in practice on Linux
only 64-bit LE is used, whereas HP-UXi only uses 32- and 64-bit big
What's more, to be suitable for C++, we may need to encode the C++ ABI for
architectures where more than one C++ compiler are common (which is just
about every platform except the free ones). But we can have that as a
I don't think the autoconf triad as a whole fits the needs. But we can
start from it and strip unnecessary parts, then append what else we may
ia64-hpux-32 (subtypes g++ and aCC)
ia64-hpux-64 (subtypes g++ and aCC)
sparc-solaris-32 (subtypes g++ and CC)
sparc-solaris-64 (subtypes g++ and CC)
Is there a suitable list we can use? I'd hate to invent such a list.
Or should we sidestep the issue and say that you have to set an
environment variable with the arch-dependent subdir of $HOME/.local/lib if
you have one?
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090630/4b076b12/attachment-0001.pgp
More information about the xdg