basedir spec and plugins

[Brian J. Tarricone]

On 2009/06/30 14:11, Thiago Macieira wrote:
> Simon McVittie wrote:
>> On Tue, 30 Jun 2009 at 04:08:26 -0300, Thiago Macieira wrote:
>>> We'll need an architecture key, which is composed by the host OS plus
>>> at least the processor main type.
>> Multiarch http://lackof.org/taggart/hacking/multiarch/ addresses this by
>> taking the CPU and OS (or CPU and kernel+OS) from
>> config.guess/config.sub, i.e.
>>
>> `/usr/share/misc/config.guess | cut -d - -f 1,3-`:
>>> 	i386-linux
>>> 	x86-64-linux
>> i386-linux-gnu, x86_64-linux-gnu
>
> What's the "gnu" part good for? The important thing here is the kernel ABI
> and the processor. (This is not a discussion of "Linux" vs "GNU/Linux")
>
> Unless there's a i386-linux-uclibc that we have to consider...

Well, yes, that's what 'gnu' here means: glibc.  Might we come into a 
case where one system has the app compiled against glibc, and another 
system has the app compiled against another libc?  Maybe, but again 
unlikely.  (That actually would be a problem, since the main app would 
link against one libc, and the plugin linking against the other, with 
unpredictable symbol overriding going on.)  How much do we care to 
support this case?

Regardless, could still tack the C++ ABI on the end, whether or not you 
include the libc type.

> We can argue as well that we don't want to solve that problem either. If
> it works for the free operating systems (where GCC seems to be the rule),
> we can be happy.

There's certainly value to supporting other combinations, but I'm not so 
sure about the cost of doing so.  I'm less concerned about the naming of 
the arch-specific dir (sure, throw all sorts of info in there if it's 
necessary; it's just a mostly-user-invisible identifier anyway), but 
worried about how apps on a single system that supports multiple arches 
would deal with looking things up when XDG_LIB_HOME is set.  But maybe 
we can just punt in that case?  Something like:

"XDG_LIB_HOME will default to $HOME/.local/lib/$ARCH_OS_ABI_STRING/. 
Implementations which wish to use this default will need to detect the 
machine architecture, operating system, and C++ ABI [etc.] at 
compile-time.  If XDG_LIB_HOME is set to a particular value, the 
application shall use that value without regard to the arch-specific 
directory.  Users who do not wish to rely on the default should take 
care to set this variable appropriately if they run applications on the 
same machine that are compiled for different architecture/OS/C++-ABI 
combinations."

Or, we could go a different route and not define XDG_LIB_HOME at all, in 
favor of something like this:

"XDG_LIBROOT_HOME [or some other name that distinguishes it] will 
default to $HOME/.local/lib/.  Implementations must append 
$ARCH_OS_ABI_STRING to that value, which can usually be discovered at 
compile-time."

This actually sounds like a decent route to take to me.  The application 
(or library) that actually knows what arch/OS/ABI/toaster it was 
compiled for, can decide the arch-specific string, and the spec only 
needs to define the format of the string and provide examples.  A 
user/sysadmin that wishes to set this won't have to worry about 
arch-clash issues.

	-brian