|
basedir spec and plugins
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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
XDG_CACHE_DIRS/HOME -> 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/
Would we also want this for executables?
XDG_BIN_HOME -> $HOME/.local/bin
As usual the names can be discussed as well :)
Stfean
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
Re: basedir spec and plugins
Em Sexta-feira 26 Junho 2009, às 15:19:48, Stefan.Kost@... escreveu:
> 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
> XDG_CACHE_DIRS/HOME -> 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/
>
> Would we also want this for executables?
> XDG_BIN_HOME -> $HOME/.local/bin
>
> As usual the names can be discussed as well :)
I think those could turn out to be useful.
However, I just don't see why you'd want that right now.
XDG stuff is there because it's shared among different applications, libraries
and toolkits. They need to know how to find the information that they require,
in order to interoperate with other applications and the desktop.
Plugins are hardly that case. They are very much application- or library-
specific. Therefore, those can store the plugins anywhere where the FHS allows
them to.
Unless you're thinking of a form of XDG plugin system, I don't see the use-
case. Can you elaborate on why you thought of this?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Software
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
Re: basedir spec and plugins
ext Thiago Macieira < thiago@...> writes:
> Unless you're thinking of a form of XDG plugin system, I don't see the use-
> case. Can you elaborate on why you thought of this?
I can't peek into Stefan's head, but one argument might be that the user
would want to control where different kinds of things are placed.
Setting XDG_LIB_DIRS/HOME would allow that, at least for the
applications that follow the base dir standard.
It's really the same argument as for not putting libraries into
/usr/share: that place should be architecture independent. You might
want to share your home directory between machines, and then need to be
careful with the plugins. (Not a very pressing concern, I admit.)
In that light, I would propose to explicitly include the machine
architecture in the defaults, always. I.e., the default for
XDG_LIB_DIRS/HOME would be
$HOME/.local/$(uname -m)/lib/
I would agree that this complicates things for the very common case of a
home directory that only ever sees a single architecture, but it would
be kinda nice from a theoretical point of view. Maybe the 32/64 bit
variations nowadays make multiple architectures interesting again.
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
Re: basedir spec and plugins
On Fri, 26 Jun 2009 at 16:08:28 +0200, Thiago Macieira wrote:
> I think those could turn out to be useful.
>
> However, I just don't see why you'd want that right now.
>
> XDG stuff is there because it's shared among different applications, libraries
> and toolkits. They need to know how to find the information that they require,
> in order to interoperate with other applications and the desktop.
In the basedir spec, surely the thing being shared is not the
config file/data file/cache, but the ability to redirect the storage of these
things to a different location with a common environment variable?
Looking at my ~/.config, I see configuration for Banshee, Brasero and Compiz,
among others. There's nothing non-application-specific about those. Similarly,
my ~/.local/share contains the VLC media library, and prectically everything
in my ~/.cache is application-specific.
My ~/.config *also* contains an autostart directory, and my ~/.local/share
*also* contains Telepathy connection manager details and a Trash directory.
However, none of those are shared because the basedir spec says so - they're
shared because the autostart spec, the Telepathy spec and the Trash spec,
respectively, say so.
So I don't see any conflict with the idea of XDG_LIB_DIRS (XDG_PLUGIN_DIRS?),
and my only objection to XDG_BIN_DIRS is that we have it already - it's called
PATH :-)
As an implementation detail, though, the default for XDG_LIB_DIRS shouldn't be
~/.local/lib - people still use NFS /home. It should probably be
something like ~/.local/lib/ARCH-OS (with ARCH and OS as defined by GNU
config.guess), analogous to < http://lackof.org/taggart/hacking/multiarch/>.
Alternatively, applications could be required to look in both
$XDG_LIB_DIRS/app-suffix and $XDG_LIB_DIRS/ARCH-OS/app-suffix
(so perhaps my current laptop would end up with GStreamer plugins in
~/.local/lib/i486-linux/gstreamer).
Simon
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
Re: basedir spec and plugins
On Fri, 2009-06-26 at 16:08 +0200, Thiago Macieira wrote:
> Unless you're thinking of a form of XDG plugin system
>
This is not a so funky option: such as exists PackageKit for abstraction
of packages management, an agnostic plugins management infrastructure
(to handle dependencies, installations, upgrades and uninstallations)
would also be desiderable.
--
Roberto -MadBob- Guido
http://claimid.com/madbob_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
Re: basedir spec and plugins
On Fri, 2009-06-26 at 15:19 +0200, Stefan.Kost@... 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
> XDG_CACHE_DIRS/HOME -> 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.
> 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.
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
Re: basedir spec and plugins
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
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
RE: basedir spec and plugins
hi,
>-----Original Message-----
>From: ext Rodney Dawes [mailto: dobey.pwns@...]
>Sent: 30 June, 2009 05:45
>To: Kost Stefan (Nokia-D/Helsinki)
>Cc: xdg@...
>Subject: Re: basedir spec and plugins
>
>On Fri, 2009-06-26 at 15:19 +0200, Stefan.Kost@... 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
>XDG_CACHE_DIRS/HOME ->
>> 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.
Stefan
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
Re: basedir spec and plugins
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
> ia64-linux-32le
> ia64-linux-64le
> ia64-linux-32be
> ia64-linux-64be
ia64-linux-gnu (is the word size/endianness differentiation really necessary,
or is there one endianness and word size that, in practice, everyone uses?
If you really need to distinguish, talk to config-patches@..., without
which software that uses autotools probably won't compile for the "other"
configurations anyway)
> ia64-hpux-32 (subtypes g++ and aCC)
> ia64-hpux-64 (subtypes g++ and aCC)
Again, config.guess doesn't seem to distinguish: does nobody actually use one
of these configurations?
> sparc-solaris-32 (subtypes g++ and CC)
> sparc-solaris-64 (subtypes g++ and CC)
> sparc-linux-32
> sparc-linux-64
sparc-solarisN, sparc-linux-gnu, sparc64-linux-gnu.
It might be worth asking the proposers of multiarch how their work relates to
C++ compiler ABIs; in principle you could have sparc-solaris3-g++3 and
sparc-solaris3-suncc, I suppose.
Simon
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
Re: basedir spec and plugins
On Tue, 2009-06-30 at 13:02 +0100, Simon McVittie wrote:
> ia64-linux-gnu (is the word size/endianness differentiation really necessary,
> or is there one endianness and word size that, in practice, everyone uses?
> If you really need to distinguish, talk to config-patches@..., without
> which software that uses autotools probably won't compile for the "other"
> configurations anyway)
>
> > ia64-hpux-32 (subtypes g++ and aCC)
> > ia64-hpux-64 (subtypes g++ and aCC)
>
> Again, config.guess doesn't seem to distinguish: does nobody actually use one
> of these configurations?
>
> > sparc-solaris-32 (subtypes g++ and CC)
> > sparc-solaris-64 (subtypes g++ and CC)
> > sparc-linux-32
> > sparc-linux-64
>
> sparc-solarisN, sparc-linux-gnu, sparc64-linux-gnu.
>
> It might be worth asking the proposers of multiarch how their work relates to
> C++ compiler ABIs; in principle you could have sparc-solaris3-g++3 and
> sparc-solaris3-suncc, I suppose.
Why not just "lib32" and "lib64"? Do we really need some significant
amount of complexity to deal with hosts/compilers/archs/etc... ?
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
Re: basedir spec and plugins
On 2009/06/30 00:08, Thiago Macieira wrote:
> 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.
Is this necessary? Would you really expect someone to have two copies
of the same app or library installed, each with a different C++ ABI
used? If not, then it's fine to keep plugins with different ABIs in the
same directory.
Also note that we're talking about desktop use here. That's the 'D' in
XDG. Who is going to have HPUX running on IA64 as a desktop machine AND
want to do something ridiculous like have two copies of the same app
installed, compiled with different C++ ABIs?
How would you set/determine this in the app when finding a default value
of XDG_LIB_HOME? What happens if XDG_LIB_HOME is set in the
environment? How does this get adjusted for any of the possible
subtypes (32/64bit, diff C++ ABI, diff endianness) when you could have
more than one available on the same machine during the same desktop session?
I think for XDG_CONFIG_HOME and XDG_CACHE_HOME at least, we assume that
you set these at the beginning of your session and they stay that way,
unchanged (aside from corner use cases or app debugging). I suppose
it's fine to have a different assumption for XDG_LIB_HOME, but it sounds
a bit over-engineered to me for desktop use.
> x86-64-linux
x86_64-linux, actually...
> sparc-solaris-32 (subtypes g++ and CC)
> sparc-solaris-64 (subtypes g++ and CC)
> sparc-linux-32
> sparc-linux-64
Wouldn't you normally use sparc/sparc64 to make that distinction
(similar to powerpc/powerpc64 or i386/x86_64)? 32-bit binaries running
on a sparc64 CPU/kernel can be considered sparc-linux.
-brian
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
Re: basedir spec and plugins
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...
>> ia64-linux-32le
>> ia64-linux-64le
>> ia64-linux-32be
>> ia64-linux-64be
>
>ia64-linux-gnu (is the word size/endianness differentiation really
> necessary, or is there one endianness and word size that, in practice,
> everyone uses? If you really need to distinguish, talk to
> config-patches@..., without which software that uses autotools
> probably won't compile for the "other" configurations anyway)
Everyone seems to use 64-bit little endian. But the kernel still has the
ability to talk to 32-bit processes and big endian ones.
>> ia64-hpux-32 (subtypes g++ and aCC)
>> ia64-hpux-64 (subtypes g++ and aCC)
>
>Again, config.guess doesn't seem to distinguish: does nobody actually
> use one of these configurations?
In this case, they do. Both 32- and 64-bit libraries are installed in the
HP-UXi box I have available. They are standard from HP. To make matters
worse, the PA-RISC binaries are also installed.
I don't think config.guess needs to know the difference, since it's just a
compiler switch away. The entire library stack is replaced by that switch
and it's transparent to the application being compiled.
However, for our case here, we need to know the difference, because we need
to know where to place the libraries/plugins.
And I don't think config.guess is working properly on HP-UXi. If I look at
the /usr/local/lib where a few packages were installed, I see a 32-bit
(only) gstreamer and a 64-bit (only) OpenSSL. The 32-bit OpenSSL is in
/usr/local/lib/hpux32.
By the way, I've just realised pkg-config doesn't work properly either.
This probably explains some of the faults I have been seeing...
>> sparc-solaris-32 (subtypes g++ and CC)
>> sparc-solaris-64 (subtypes g++ and CC)
>> sparc-linux-32
>> sparc-linux-64
>
>sparc-solarisN, sparc-linux-gnu, sparc64-linux-gnu.
>
>It might be worth asking the proposers of multiarch how their work
> relates to C++ compiler ABIs; in principle you could have
> sparc-solaris3-g++3 and sparc-solaris3-suncc, I suppose.
I don't think they do. Reading the webpage you posted the link to, it
looks like they're only looking at solving the Linux/FHS problem.
I don't think they're interested more "exotic Unix" flavours or C++ ABI
issues.
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.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
Re: basedir spec and plugins
Brian J. Tarricone wrote:
>On 2009/06/30 00:08, Thiago Macieira wrote:
>> 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.
>
>Is this necessary? Would you really expect someone to have two copies
>of the same app or library installed, each with a different C++ ABI
>used? If not, then it's fine to keep plugins with different ABIs in the
>same directory.
We're not talking about the same app here. If we were, then the plugins
would be placed in this application's specific directories and we wouldn't
be having this discussion.
I believe we're talking here about generic application plugins, that can
be used for all applications. I don't have a use-case for it (see my
earlier emails on the thread), but it could happen in the future.
And, in any case, it could be the same app as well, if we consider that
$HOME is often mounted from an NFS server. So it's not too far-fetched to
imagine two different systems with two different builds sharing an NFS
mount.
>Also note that we're talking about desktop use here. That's the 'D' in
>XDG. Who is going to have HPUX running on IA64 as a desktop machine AND
>want to do something ridiculous like have two copies of the same app
>installed, compiled with different C++ ABIs?
Well, then think of Solaris, where KDE does run on. And it can be compiled
with both Sun CC and GCC. And they are binary incompatible.
Interestingly, in the HP-UXi on IA-64 case, the ABI is technically the
same because that's the platform where GCC's current C++ ABI comes from:
the Itanium C++ ABI. The HP C++ compiler uses it too. Of course, the
problem still applies because the standard C++ libraries are different.
>How would you set/determine this in the app when finding a default value
>of XDG_LIB_HOME? What happens if XDG_LIB_HOME is set in the
>environment? How does this get adjusted for any of the possible
>subtypes (32/64bit, diff C++ ABI, diff endianness) when you could have
>more than one available on the same machine during the same desktop
> session?
Those are the questions this thread is trying to answer.
>> sparc-solaris-32 (subtypes g++ and CC)
>> sparc-solaris-64 (subtypes g++ and CC)
>> sparc-linux-32
>> sparc-linux-64
>
>Wouldn't you normally use sparc/sparc64 to make that distinction
>(similar to powerpc/powerpc64 or i386/x86_64)? 32-bit binaries running
>on a sparc64 CPU/kernel can be considered sparc-linux.
Good point. I was thinking of a SPARC 64-bit machine running 32-bit
binaries, but of course those are the same as SPARC 32-bit binaries.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
Re: basedir spec and plugins
On 2009/06/30 14:22, Thiago Macieira wrote:
> Brian J. Tarricone wrote:
>> On 2009/06/30 00:08, Thiago Macieira wrote:
>>> 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.
>>
>> Is this necessary? Would you really expect someone to have two copies
>> of the same app or library installed, each with a different C++ ABI
>> used? If not, then it's fine to keep plugins with different ABIs in the
>> same directory.
>
> We're not talking about the same app here. If we were, then the plugins
> would be placed in this application's specific directories and we wouldn't
> be having this discussion.
>
> I believe we're talking here about generic application plugins, that can
> be used for all applications. I don't have a use-case for it (see my
> earlier emails on the thread), but it could happen in the future.
Ok, fair enough. The fact that nothing like this seems to exist, and
that plugin systems have been around for decades kinda suggests this
isn't a likely use-case, but... sure, anything can happen.
> And, in any case, it could be the same app as well, if we consider that
> $HOME is often mounted from an NFS server. So it's not too far-fetched to
> imagine two different systems with two different builds sharing an NFS
> mount.
True enough.
>> Also note that we're talking about desktop use here. That's the 'D' in
>> XDG. Who is going to have HPUX running on IA64 as a desktop machine AND
>> want to do something ridiculous like have two copies of the same app
>> installed, compiled with different C++ ABIs?
>
> Well, then think of Solaris, where KDE does run on. And it can be compiled
> with both Sun CC and GCC. And they are binary incompatible.
Who in their right mind would compile two copies of KDE (or anything
aside from some lowlevel system libs) using two different C++ ABIs?
But yeah, I guess you still have the case of the NFS-mounted homedir to
contend with; even if it's pretty unlikely that a user would mount that
homedir on two different machines of the same arch but with apps
compiled using a different C++ compiler.
-brian
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
Re: basedir spec and plugins
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
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
Re: basedir spec and plugins
Thiago Macieira wrote:
>>Also note that we're talking about desktop use here. That's the 'D' in
>>XDG. Who is going to have HPUX running on IA64 as a desktop machine
>> AND want to do something ridiculous like have two copies of the same
>> app installed, compiled with different C++ ABIs?
>
>Well, then think of Solaris, where KDE does run on. And it can be
> compiled with both Sun CC and GCC. And they are binary incompatible.
>
>Interestingly, in the HP-UXi on IA-64 case, the ABI is technically the
>same because that's the platform where GCC's current C++ ABI comes from:
>the Itanium C++ ABI. The HP C++ compiler uses it too. Of course, the
>problem still applies because the standard C++ libraries are different.
Let's face it: we're not going to solve the C++, ABI and base libraries
issue. The more I think about it, the more I see we'd open a can of worms
by trying to.
And don't get me started on Windows, where Microsoft breaks full BC with
every new Service Pack of their compiler. Let's say Windows users
willingly put themselves at the mercy of Microsoft, so we won't try to
solve there either.
Also, no self-respecting dynamic linker will load binaries that are for a
different word size or endianness. And the OS ABI wouldn't be a problem if
it were checked consistently -- it isn't. I've just checked that the Linux
ELF loader and it doesn't verify the OSABI, even though libdl does.
Finally, the dynamic loader already tries to find libraries in sub-paths.
The only problem is that dlopen doesn't apply this technique if there's a
slash in the library name.
So either we use an arch-os combination like multiarch proposes, or we can
reuse LD_LIBRARY_PATH.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
Re: basedir spec and plugins
On Tue, 30 Jun 2009 at 18:11:32 -0300, 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")
Partly knowing it's glibc, and partly the fact that someone has already written
a fairly comprehensive list of architectures for us, meaning that we don't
have to. Things like multiarch and bits of the Debian build system normatively
reference config.{guess,sub} as their source of architecture and OS names
(e.g. `dpkg-architecture` includes things like DEB_HOST_GNU_TYPE, which is
exactly the string we want).
Because "someone" is GNU in this case, the usual politics apply and they call
it linux-gnu, but surely 4 characters are a small price to pay for not having
to duplicate the work done in config.{guess,sub}?
S
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
RE: basedir spec and plugins
hi,
<snip>
>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.
>
I like
"XDG_LIB_HOME will default to $HOME/.local/lib/$ARCH_OS_ABI_STRING/
more as this allows the distro/admin to set it up and developers can just put a binary there.
If we go for XDG_LIBROOT_HOME, we'll have to define $ARCH_OS_ABI_STRING.
Stefan
> -brian
>_______________________________________________
>xdg mailing list
> xdg@...
> http://lists.freedesktop.org/mailman/listinfo/xdg>
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
|
Re: basedir spec and plugins
On 07/15/2009 04:52 AM, Stefan.Kost@... wrote:
>
> I like
> "XDG_LIB_HOME will default to $HOME/.local/lib/$ARCH_OS_ABI_STRING/
> more as this allows the distro/admin to set it up and developers can just put a binary there.
>
> If we go for XDG_LIBROOT_HOME, we'll have to define $ARCH_OS_ABI_STRING.
Don't we have to do that regardless?
Well, ok, I suppose we don't strictly *have* to, but if different
distros define it in different ways, that would be pretty ugly. Not
necessarily a practical problem, but certainly somewhat against the
spirit of standardizing.
-brian
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg
|
signature.asc (196 bytes) 