On Wed, May 24, 2017 at 3:35 AM, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Wed, 2017-04-26 at 17:57 +0200, Michael Matz wrote:
As I said, modules (i.e. DSOs that are used with dlopen, not loaded by ld.so) would be placed into (subdirs of) libexec (conceptually (to me) they are more similar to helper executables than shared libraries; they just happen to be implemented via shared library mechanisms)
Let's take a very practical example, showing that this can't work:
e.g libproxy (the library) and any of it's modules e.g. libproxy- config-
The lib is obviously in /usr/lib64/libproxy.so.1 the config module to it (arch dependent, loaded dynamically) in /usr/lib64/libproxy-%{version}/modules/config-gnome3.so
libproxy being used by quite some low-level things is also provided as biarch, so we have libproxy1-32bit (/usr/lib/libproxy.so.1)
the 23bit variant on a 64bit system obviously needs to find it's modules in a path that are not equal to the 64bit variant.
Putting that stuff into libexec sounds totally weird and would just require to split stuff up even weirder...
=> modules loaded by a lib belong in my opinion to %{_libdir}/%{name}
I don't disagree with that. If it's a dylib/so file, then it belongs in the private directory under %_libdir, especially if it's being loaded by a library. libexec is for helper programs only. That is, programs that are executed by other programs but should never be run by users. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org