basedir spec and plugins

[Thiago Macieira]

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

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

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

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

So:
	i386-linux
	x86-64-linux
	ia64-linux-32le
	ia64-linux-64le
	ia64-linux-32be
	ia64-linux-64be
	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)
	sparc-linux-32
	sparc-linux-64

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
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090630/4b076b12/attachment-0001.pgp