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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
