Re: Base Directory Specification and plugins
On Thursday 15 December 2011 23:35:34 Yury G. Kudryashov wrote:
David Faure wrote:
On Sunday 11 December 2011 15:16:32 Yury G. Kudryashov wrote:
Plugins should be installed to
${INSTALL_PREFIX}/lib${LIB_SUFFIX}${LIBRARY_SPECIFIC_SUFFIX}.
${LIB_SUFFIX} should be chosen in the same way that is used for shared
libraries.
Buildsystem of a plugin-enabled library/application should (must?) allow
distributions to override LIB_SUFFIX and may allow override of
LIBRARY_SPECEFIC_SUFIX.
Overriding the library suffix? If you install a plugin for qt, it has to
go into /usr/lib/plugins/qt, if that's where all your qt plugins go. If a
single plugin is compiled with an overriden library suffix of foobar,
then your plugin /usr/lib/plugins/foobar will feel quite alone and ignored
:)
Overriding the LIBRARY_SPECIFIC_SIFFIX while compiling the library, not a
plugin. E.g., `./configure --plugin-suffix=qt` for plugins in
$prefix/lib/plugins/qt or `./configure --plugin-suffix=qt4` for plugins in
$prefix/lib/plugins/qt4.
Ah OK. Nice to have, but not really a hard requirement.
Both LIB_SUFFIX ad LIBRARY_SPECIFIC_SUFFIX must be advertised through
installed development files (e.g., mylib.pc or MyLibConfig.cmake).
Yes (well, or just the full path where to install plugins?)
Either both parts or the full path _relative_ to the installation prefix.
The absolute path makes no sense if I'm installing a plugin to my home
directory.
Right, relative path is the best solution.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Base Directory Specification and plugins
On Sunday 11 December 2011 15:16:32 Yury G. Kudryashov wrote:
XDG_PLUGIN_DIRS: either /usr/lib${LIB_SUFFIX} or
/usr/lib${LIB_SUFFIX}/plugins - what do you prefer?
Definitely the second one.
Otherwise people tend to confuse shared libs and plugins, and start linking to
plugins, and this creates trouble (it's not portable, it mixes concepts, etc.)
If we choose /usr/lib${LIB_SUFFIX}/plugins, it is easier to find all your
plugins.
The text below is written for the /usr/lib${LIB_SUFFIX} case but it is easy
to add /plugins to appropriate places.
XDG_PLUGIN_HOME: ~/.local/lib${LIB_SUFFIX} (or
~/.local/lib${LIB_SUFFIX}/plugins)
Yep. This might have to be adjusted for multi-arch setups, where shared libs
are already getting installed into /usr/lib/{TUPLE}/, for instance
/usr/lib/i386-linux-gnu/.
In that case plugins would go into /usr/lib/i386-linux-gnu/plugins.
Anyway, this could be seen as a special case of your definition, where
LIB_SUFFIX is set to /i386-linux-gnu :-)
Plugins should be installed to
${INSTALL_PREFIX}/lib${LIB_SUFFIX}${LIBRARY_SPECIFIC_SUFFIX}. ${LIB_SUFFIX}
should be chosen in the same way that is used for shared libraries.
Buildsystem of a plugin-enabled library/application should (must?) allow
distributions to override LIB_SUFFIX and may allow override of
LIBRARY_SPECEFIC_SUFIX.
Overriding the library suffix? If you install a plugin for qt, it has to go
into
/usr/lib/plugins/qt, if that's where all your qt plugins go. If a single
plugin is compiled with an overriden library suffix of foobar, then your
plugin /usr/lib/plugins/foobar will feel quite alone and ignored :)
This is important because different distros may
prefer different ABI-specific LIB_SUFFIX'es.
Yes.
Both LIB_SUFFIX ad LIBRARY_SPECIFIC_SUFFIX must be advertised through
installed development files (e.g., mylib.pc or MyLibConfig.cmake).
Yes (well, or just the full path where to install plugins?)
Buildsystem of a plugin should install plugins into
${prefix}/lib${LIB_SUFFIX}/${LIBRARY_SPECIFIC_SUFFIX}, where ${prefix} is
the plugin's installation prefix (not the prefix of the original
library/application), LIB_SUFFIX and LIBRARY_SPECIFIC_SUFFIX are taken from
mylib.pc or MyLibConfig.cmake. If the installation prefix of the plugin
differs from the installation prefix of the original library/application,
plugin may (should?) tell user to adjust XDG_PLUGIN_DIRS.
Yes. May. It's not like installing a lib into /opt/foo/lib currently tells
anyone to set LD_LIBRARY_PATH. The way to document setup should be left to
individual implementations.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Base Directory Specification and plugins
David Faure wrote:
On Sunday 11 December 2011 15:16:32 Yury G. Kudryashov wrote:
Plugins should be installed to
${INSTALL_PREFIX}/lib${LIB_SUFFIX}${LIBRARY_SPECIFIC_SUFFIX}.
${LIB_SUFFIX} should be chosen in the same way that is used for shared
libraries.
Buildsystem of a plugin-enabled library/application should (must?) allow
distributions to override LIB_SUFFIX and may allow override of
LIBRARY_SPECEFIC_SUFIX.
Overriding the library suffix? If you install a plugin for qt, it has to
go into /usr/lib/plugins/qt, if that's where all your qt plugins go. If a
single plugin is compiled with an overriden library suffix of foobar,
then your plugin /usr/lib/plugins/foobar will feel quite alone and ignored
:)
Overriding the LIBRARY_SPECIFIC_SIFFIX while compiling the library, not a
plugin. E.g., `./configure --plugin-suffix=qt` for plugins in
$prefix/lib/plugins/qt or `./configure --plugin-suffix=qt4` for plugins in
$prefix/lib/plugins/qt4.
Later every package that wants to install a plugin will read this setting
from QtCore.pc or QtConfig.cmake.
Both LIB_SUFFIX ad LIBRARY_SPECIFIC_SUFFIX must be advertised through
installed development files (e.g., mylib.pc or MyLibConfig.cmake).
Yes (well, or just the full path where to install plugins?)
Either both parts or the full path _relative_ to the installation prefix.
The absolute path makes no sense if I'm installing a plugin to my home
directory.
--
Yury G. Kudryashov,
mailto: ur...@mccme.ru
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Base Directory Specification and plugins
On Tuesday 06 September 2011 23:02:21 Yury G. Kudryashov wrote:
Yury G. Kudryashov wrote:
What do you think about $XDG_LIBRARY_DIRS${LIB_SUFFIX},
If anything, this should be called XDG_PLUGIN_DIRS or XDG_PLUGIN_PATH.
To make it clear that it's about dlopened plugins, not about shared libraries
(which LD_LIBRARY_PATH is about).
There is one issue with pointing everyone (kde, Qt, gtk, gst etc.) to the same
directory though : unless the plugins are known by name already (e.g. via a
.desktop file), the common implementation (e.g. in Qt 4) is iterate over all
plugins in the directory and open them all. This can easily crash if the
plugins load incompatible libraries. For this reason Qt uses known subdirs
(plugindir/{designer, imageformats, sqldrivers, crypto, etc.))
but if other frameworks use the same subdir names, then it will still happen,
opening a plugin that loads an incompat library (e.g. older libpng, libc,
whatever) and crash.
Ah, so that's what your LIBRARY_SPECIFIC_SUFFIX was about, right?
To make that easier to understand, please don't define it as being part of
LIB_SUFFIX, LIB_SUFFIX is usually only arch stuff.
A mandatory implementation-specific suffix (subdir) is orthogonal, and very
much needed too, indeed.
Sorry for answering my own e-mail. What is the standard process of adding
something to the xdg dirs standard? Should I prepare a patch with exact
phrasing?
I guess so.
E.g. at the moment I'm missing some information on what the default value
would be :-)
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Base Directory Specification and plugins
David Faure wrote:
First of all, thanks a lot for your answer!
On Tuesday 06 September 2011 23:02:21 Yury G. Kudryashov wrote:
Yury G. Kudryashov wrote:
What do you think about $XDG_LIBRARY_DIRS${LIB_SUFFIX},
If anything, this should be called XDG_PLUGIN_DIRS or XDG_PLUGIN_PATH.
OK.
Ah, so that's what your LIBRARY_SPECIFIC_SUFFIX was about, right?
Yes, thanks.
To make that easier to understand, please don't define it as being part
of LIB_SUFFIX, LIB_SUFFIX is usually only arch stuff.
A mandatory implementation-specific suffix (subdir) is orthogonal, and
very much needed too, indeed.
Sorry for answering my own e-mail. What is the standard process of adding
something to the xdg dirs standard? Should I prepare a patch with exact
phrasing?
I guess so.
I hope that I'll have some time do it next week-end.
E.g. at the moment I'm missing some information on what the default value
would be :-)
XDG_PLUGIN_DIRS: either /usr/lib${LIB_SUFFIX} or
/usr/lib${LIB_SUFFIX}/plugins - what do you prefer?
If we choose /usr/lib${LIB_SUFFIX}/plugins, it is easier to find all your
plugins.
The text below is written for the /usr/lib${LIB_SUFFIX} case but it is easy
to add /plugins to appropriate places.
XDG_PLUGIN_HOME: ~/.local/lib${LIB_SUFFIX} (or
~/.local/lib${LIB_SUFFIX}/plugins)
Plugins should be installed to
${INSTALL_PREFIX}/lib${LIB_SUFFIX}${LIBRARY_SPECIFIC_SUFFIX}. ${LIB_SUFFIX}
should be chosen in the same way that is used for shared libraries.
Buildsystem of a plugin-enabled library/application should (must?) allow
distributions to override LIB_SUFFIX and may allow override of
LIBRARY_SPECEFIC_SUFIX. This is important because different distros may
prefer different ABI-specific LIB_SUFFIX'es.
Both LIB_SUFFIX ad LIBRARY_SPECIFIC_SUFFIX must be advertised through
installed development files (e.g., mylib.pc or MyLibConfig.cmake).
Buildsystem of a plugin should install plugins into
${prefix}/lib${LIB_SUFFIX}/${LIBRARY_SPECIFIC_SUFFIX}, where ${prefix} is
the plugin's installation prefix (not the prefix of the original
library/application), LIB_SUFFIX and LIBRARY_SPECIFIC_SUFFIX are taken from
mylib.pc or MyLibConfig.cmake. If the installation prefix of the plugin
differs from the installation prefix of the original library/application,
plugin may (should?) tell user to adjust XDG_PLUGIN_DIRS.
--
Yury G. Kudryashov,
mailto: ur...@mccme.ru
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Base Directory Specification and plugins
В сообщении от 11 декабря 2011 09:04:17 вы написали: On Wed, Aug 31, 2011 at 4:28 PM, Yury G. Kudryashov Replying to the list. Hi Why are these outside /usr or /usr/local to begin with? It seems like the initial premise is asking XDG to make an exception which subverts FHS. Example: a lot of software compiled by one user for many other users (say, on a shared hosting). Why you're against XDG_PLUGIN_DIRS but not XDG_DATA_DIRS and XDG_CONFIG_DIRS? Instead, XDG could add `XDG_LOCAL_HOME` / `XDG_LOCAL_DIRS`. That would be generally helpful in many cases, including yours, albeit not exactly what was asked for. If XDG_LOCAL_DIRS is a set of prefixes, defaults to /usr/local:/usr and every program should look for plugins/data/config, then it is OK for me. Isolating LIBRARY Not libraries (there is LD_LIBRARY_PATH) but dlopen'd plugins. out special so people can put them willy-nilly wherever they like sounds like a slippery slope. Will others ask for XDG_BIN_DIRS, There exists $PATH XDG_MAN_DIRS, There exists $MANPATH etc? -- Yury G. Kudryashov, mailto: ur...@mccme.ru signature.asc Description: This is a digitally signed message part. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Base Directory Specification and plugins
Yury G. Kudryashov wrote:
Sorry for answering my own e-mail. What is the standard process of adding
something to the xdg dirs standard? Should I prepare a patch with exact
phrasing? Should I wait for more feedback before working on the patch?
Simon McVittie wrote:
On Thu, 01 Sep 2011 at 00:28:37 +0400, Yury G. Kudryashov wrote:
I'm replying to an old thread. The original thread can be found here:
http://lists.freedesktop.org/archives/xdg/2010-November/011722.html
Simon McVittie wrote:
The most general and widely used naming scheme for ABIs in Free
Software seems to be the GNU triplets used by autoconf and gcc,
which look like CPU-OS or CPU-KERNEL-OS (e.g. x86_64-linux-gnu for
Linux with GNU libc on x86-64, arm-linux-uclibc for Linux with uclibc
on ARM, i486-freebsd for FreeBSD (both kernel and libc) on x86, or
whatever).
What do you think about $XDG_LIBRARY_DIRS${LIB_SUFFIX},
$XDG_LIBRARY_HOME${LIB_SUFFIX}, where LIB_SUFFIX is fixed during library
compilation and should be available through
MyLib.pc/MyLibConfig.cmake/whatever? This looks easier to implement.
Perhaps; or /${LIB_SUFFIX},
This is a particular case of my proposal: just set my LIB_SUFFIX to
/${YOUR_LIB_SUFFIX}.
which is essentially Debian-style multiarch.
I can't help thinking that the ABI naming should be the same for the
whole platform rather than being something you query per-library, but
hopefully one day everyone will be using multiarch anyway.
What about the following algorithm:
* A library/application provides a way to set LIB_SUFFIX at configure
time.
It can default to /${GNU_TRIPPLE} or /64 but distro packages should
have a way to override it.
* A library/application advertices its LIB_SUFFIX somehow.
* Plugin's buildsystem installs plugin into LIB_SUFFIX advertised by
library.
BTW, for most libraries LIB_SUFFIX will be
/${GNU_TRIPPLE}/${LIBRARY_SPECIFIC_SUFFIX}. E.g., KDE currently loads
plugins from $KDEDIRS/lib/kde4 and adds $KDEDIRS/lib/kde4/plugins to
$QT_PLUGIN_PATH.
--
Yury G. Kudryashov,
mailto: ur...@mccme.ru
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Base Directory Specification and plugins
On Thu, 01 Sep 2011 at 00:28:37 +0400, Yury G. Kudryashov wrote:
I'm replying to an old thread. The original thread can be found here:
http://lists.freedesktop.org/archives/xdg/2010-November/011722.html
Simon McVittie wrote:
The most general and widely used naming scheme for ABIs in Free
Software seems to be the GNU triplets used by autoconf and gcc, which
look like CPU-OS or CPU-KERNEL-OS (e.g. x86_64-linux-gnu for Linux with
GNU libc on x86-64, arm-linux-uclibc for Linux with uclibc on ARM,
i486-freebsd for FreeBSD (both kernel and libc) on x86, or whatever).
What do you think about $XDG_LIBRARY_DIRS${LIB_SUFFIX},
$XDG_LIBRARY_HOME${LIB_SUFFIX}, where LIB_SUFFIX is fixed during library
compilation and should be available through
MyLib.pc/MyLibConfig.cmake/whatever? This looks easier to implement.
Perhaps; or /${LIB_SUFFIX}, which is essentially Debian-style multiarch.
I can't help thinking that the ABI naming should be the same for the whole
platform rather than being something you query per-library, but hopefully one
day everyone will be using multiarch anyway.
Since the old thread, Debian multiarch support has gone from will happen one
day to actually happening - it's in Ubuntu 11.04 (released), and
mostly in Debian 7 (under development). The names we use for architectures
are now defined as the GNU tuple for the most generic member of a compatible
family of ABIs: for instance:
* i386-linux-gnu (never a specific processor level like i486, even though
Debian binaries actually require i486 and Ubuntu binaries require i686)
* arm-linux-gnueabi (never a specific processor like armv4t-linux-gnueabi,
even though the actual binaries have a minimum CPU level, currently ARM v4
I think)
* x86_64-kfreebsd-gnu (there's only one GNU CPU name for x86-64 anyway)
* arm-linux-gnueabihf
* arm-linux-gnu (the incompatible ARM old ABI - which was dropped after
Debian 5, but if we still supported it, this is what it'd be called)
* i386-freebsd (hypothetically, if FreeBSD adopted Debian-style multiarch,
this is what they'd use)
I think the best-practice should be to use the same GNU tuple made generic
for the library suffix that Debian is using for multiarch; or failing that,
the next best thing would be to use the GNU tuple for which the library
was built (which is something the compiler already knows), and query it from
the library's pkg-config file.
In the common case of x86-64 on GNU/Linux, the Debian multiarch tuple is the
same as the GNU triplet anyway.
S
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Base Directory Specification and plugins
Simon McVittie wrote:
On Thu, 01 Sep 2011 at 00:28:37 +0400, Yury G. Kudryashov wrote:
I'm replying to an old thread. The original thread can be found here:
http://lists.freedesktop.org/archives/xdg/2010-November/011722.html
Simon McVittie wrote:
The most general and widely used naming scheme for ABIs in Free
Software seems to be the GNU triplets used by autoconf and gcc, which
look like CPU-OS or CPU-KERNEL-OS (e.g. x86_64-linux-gnu for Linux with
GNU libc on x86-64, arm-linux-uclibc for Linux with uclibc on ARM,
i486-freebsd for FreeBSD (both kernel and libc) on x86, or whatever).
What do you think about $XDG_LIBRARY_DIRS${LIB_SUFFIX},
$XDG_LIBRARY_HOME${LIB_SUFFIX}, where LIB_SUFFIX is fixed during library
compilation and should be available through
MyLib.pc/MyLibConfig.cmake/whatever? This looks easier to implement.
Perhaps; or /${LIB_SUFFIX},
This is a particular case of my proposal: just set my LIB_SUFFIX to
/${YOUR_LIB_SUFFIX}.
which is essentially Debian-style multiarch.
I can't help thinking that the ABI naming should be the same for the whole
platform rather than being something you query per-library, but hopefully
one day everyone will be using multiarch anyway.
What about the following algorithm:
* A library/application provides a way to set LIB_SUFFIX at configure time.
It can default to /${GNU_TRIPPLE} or /64 but distro packages should
have a way to override it.
* A library/application advertices its LIB_SUFFIX somehow.
* Plugin's buildsystem installs plugin into LIB_SUFFIX advertised by
library.
BTW, for most libraries LIB_SUFFIX will be
/${GNU_TRIPPLE}/${LIBRARY_SPECIFIC_SUFFIX}. E.g., KDE currently loads
plugins from $KDEDIRS/lib/kde4 and adds $KDEDIRS/lib/kde4/plugins to
$QT_PLUGIN_PATH.
--
Yury G. Kudryashov,
mailto: ur...@mccme.ru
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Base Directory Specification and plugins
On 11/22/10 5:31 AM, Simon McVittie wrote: Current proposals for multiarch in LSB and Debian-derived distributions http://lackof.org/taggart/hacking/multiarch/, http://wiki.debian.org/multiarch, https://wiki.ubuntu.com/MultiarchSpec) use GNU triplets to name subdirectories of /usr/lib, e.g. /usr/lib/arm-linux-gnu. So, I'd suggest mirroring those and using ~/.lib/CPU-[KERNEL-]OS/myapp/*.so. Hmm... I hadn't considered multiarch but you bring up some great points. Although I don't see why it couldn't be ~/.local/lib*. Since as I mentioned earlier, it seems like the share directory in ~/.local is either there for expansion or to just classify things further than they need to be. Regards, S -- Gary Kramlich g...@reaperworld.com ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Base Directory Specification and plugins
Hi, On 11/22/10 5:31 AM, Simon McVittie wrote: So, I'd suggest mirroring those and using ~/.lib/CPU-[KERNEL-]OS/myapp/*.so. With only slight hesitation due to fears of political correctness, I'd suggest using Debian arch names here. They tend to be an awful lot more sane for this purpose. Cheers ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Base Directory Specification and plugins
Le dimanche 21 novembre 2010 09:28:20 Ryan Lortie, vous avez écrit : Having a separate 'lib' directory doesn't automatically solve the problem associated with trying to use a home directory that contains binaries on multiple different architectures. It's just a name. This problem is not specific to architecture-dependent data. If your home is exported via NFS, applications from different systems (possibly of the same architecture) may access it. You may in particular end up with conflicting versions of the same application. For instance, an older version could systematically 'erase' new settings from a configuration file that it shares with the newer version, because it does not understand them those settings. Or it might simply fail to start completely due to syntactical problems So I don't really get your point against 'lib'. It seems more like a point against sharing home directories within an heterogenous set of systems altogether. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Base Directory Specification and plugins
On Tue, 23 Nov 2010 at 13:42:32 -0500, Ryan Lortie wrote: With only slight hesitation due to fears of political correctness, I'd suggest using Debian arch names here. They tend to be an awful lot more sane for this purpose. Speaking as a Debian Developer: they're much shorter, but you might notice that Debian and Ubuntu aren't planning to use these strings for multiarch. They're OK as CPU architecture names, but now that dpkg supports non-Linux ports (kfreebsd-i386, kfreebsd-amd64, hurd-i386) they're really showing their limitations, and people only define them for platforms that make sense as targets for dpkg. By the time you include all the misc that defines an ABI (like distinguishing between OABI and EABI on ARM Linux) you'd more or less end up reinventing GNU triplets. GNU triplets have the advantage that by the time you get a port to any platform up and running, if you're using gcc (even as a cross-compiler), you've already chosen a GNU triplet for that platform. For Debian users, Debian arch names do map to GNU triplets rather easily, via dpkg-architecture(1): % dpkg-architecture -aamd64 -qDEB_HOST_GNU_TYPE x86_64-linux-gnu % dpkg-architecture -amipsel -qDEB_HOST_GNU_TYPE dpkg-architecture: warning: Specified GNU system type mipsel-linux-gnu does not match gcc system type x86_64-linux-gnu. mipsel-linux-gnu % dpkg-architecture -ahurd-i386 -qDEB_HOST_GNU_TYPE dpkg-architecture: warning: Specified GNU system type i486-gnu does not match gcc system type x86_64-linux-gnu. i486-gnu Regards, S ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Base Directory Specification and plugins
On Tue, 23.11.10 13:42, Ryan Lortie (de...@desrt.ca) wrote: Hi, On 11/22/10 5:31 AM, Simon McVittie wrote: So, I'd suggest mirroring those and using ~/.lib/CPU-[KERNEL-]OS/myapp/*.so. With only slight hesitation due to fears of political correctness, I'd suggest using Debian arch names here. They tend to be an awful lot more sane for this purpose. Why not use utsname.sysname[] plus utsname.machine[]? i.e. the output of uname -sm: $ uname -sm Linux x86_64 Lennart -- Lennart Poettering - Red Hat, Inc. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Base Directory Specification and plugins
On Sun, 21 Nov 2010 at 02:28:20 -0500, Ryan Lortie wrote:
On Sat, 2010-11-20 at 20:15 -0600, Gary Kramlich wrote:
That leaves the data directory. However, the data directory on a unix
machine ends up being ~/.local/share and putting a native plugin under a
share directory seems to be completely wrong to me.
Your concern here is misplaced. You can logically claim that it is
either completely incorrect to place native binaries in the user home
directory or that it is safe to blindly do so without consideration of
the share vs. lib issue. Which one you choose depends on your
assumption about the different sorts of computers that the user's home
directory might end up being used on.
There's been discussion of this issue on this list before. One way to support
sharing a home directory between ABIs (imagine an NFS $HOME that can be mounted
from an x86, x86-64 or arm machine) without colliding is to put the
libraries in an ABI-specific directory, or give them ABI-specific
names, or something.
The most general and widely used naming scheme for ABIs in Free
Software seems to be the GNU triplets used by autoconf and gcc, which look
like CPU-OS or CPU-KERNEL-OS (e.g. x86_64-linux-gnu for Linux with GNU libc on
x86-64, arm-linux-uclibc for Linux with uclibc on ARM, i486-freebsd for
FreeBSD (both kernel and libc) on x86, or whatever).
One common practice for cross-compilation is to put the cross-compiler and
host libraries in /usr/CPU-[KERNEL-]OS, e.g. /usr/arm-linux-gnu/{bin,lib};
cross-compiler binaries are also typically called something like
arm-linux-gnu-gcc, where arm-linux-gnu is the host system (the system where
the binaries produced by this compiler are going to be used).
Current proposals for multiarch in LSB and Debian-derived distributions
http://lackof.org/taggart/hacking/multiarch/,
http://wiki.debian.org/multiarch, https://wiki.ubuntu.com/MultiarchSpec) use
GNU triplets to name subdirectories of /usr/lib, e.g. /usr/lib/arm-linux-gnu.
So, I'd suggest mirroring those and using ~/.lib/CPU-[KERNEL-]OS/myapp/*.so.
autoconf's config.guess/config.sub produce a related construct, CPU-MACHINE-OS
or CPU-MACHINE-KERNEL-OS, but the MACHINE part is mostly obsolete these days -
it comes out as 'unknown' or 'pc' in most environments - and doesn't seem to be
relevant to ABIs (cross-compilation didn't traditionally use it, and multiarch
doesn't use it either).
Regards,
S
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Base Directory Specification and plugins
On 11/21/2010 01:28 AM, Ryan Lortie wrote: Hi Gary, On Sat, 2010-11-20 at 20:15 -0600, Gary Kramlich wrote: That leaves the data directory. However, the data directory on a unix machine ends up being ~/.local/share and putting a native plugin under a share directory seems to be completely wrong to me. Your concern here is misplaced. You can logically claim that it is either completely incorrect to place native binaries in the user home directory or that it is safe to blindly do so without consideration of the share vs. lib issue. Which one you choose depends on your assumption about the different sorts of computers that the user's home directory might end up being used on. If I didn't want to put native libraries in the user's home directory, then I wouldn't have run into this dilemma. You're right though, it is just a name, but that makes me wonder why there was a separation of cache, config, and data then... Having a separate 'lib' directory doesn't automatically solve the problem associated with trying to use a home directory that contains binaries on multiple different architectures. It's just a name. I completely agree, but a plugin is not data, config, or cache, at least according to the definitions given in the specification. If the point of XDG_DATA_HOME is just for data that typically would go under a share directory (examples, pixmaps, etc) then why even have the share directory under .local? It seems to me that by adding another sub directory to ~/.local for data, that there was intent to expand on what could go in ~/.local in which case putting plugins and libraries in a lib sub directory makes total sense, at least to me. Cheers -- Gary Kramlich g...@reaperworld.com signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Base Directory Specification and plugins
I'm working on an application where I want to allow user plugins. However, while trying to follow the Base Directory specification, I realized that this seems to be overlooked in the specification. What I mean here, is that neither the cache, config, or data directories seem to be the correct place to put a native plugin. Obviously config is out right away since it's not configuration data, and cache is out since a plugin isn't necessarily non-essential. That leaves the data directory. However, the data directory on a unix machine ends up being ~/.local/share and putting a native plugin under a share directory seems to be completely wrong to me. What I'm purposing is a XDG_LIBRARY_DIR which would point to ~/.local/lib and have an XDG_LIBRARY_DIRS counterpart that would list off /usr/lib, /usr/local/lib, and so on. I have no idea if this is the best solution, but look forward to any comments about how to fix my problem while following the specification. Thanks, -- Gary Kramlich g...@reaperworld.com signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
