[opensuse-packaging] Why %_libexecdir is not arch dependent?
I am thinking about /usr/lib/gstreamer-0.10/gst-plugin-scanner, that apparently can't detect 32bit gstreamer plugins: (gst-plugin-scanner:18379): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstcoreelements.so': /usr/lib/gstreamer-0.10/libgstcoreelements.so: wrong ELF class: ELFCLASS32 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Cristian Morales Vega (reddwarf@opensuse.org) [20120510 01:05]:
I am thinking about /usr/lib/gstreamer-0.10/gst-plugin-scanner, that apparently can't detect 32bit gstreamer plugins:
(gst-plugin-scanner:18379): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstcoreelements.so': /usr/lib/gstreamer-0.10/libgstcoreelements.so: wrong ELF class: ELFCLASS32
There is no real standard regarding libexecdir. It is defined in the GNU coding standard http://www.gnu.org/prep/standards/html_node/Directory-Variables.html And that isn't very precise. My POV is that the wrong place was choosen for the plugins. They should either have used arch specific dirs below $(libexecdir)/@PACKAGE@ or (which is easier) used $(libdir)/@PACKAGE@. All in all this is a discussion that should happen upstream since it's up to the upstream project to decide about the correct place in the presence of biarch platforms. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 10 May 2012, Philipp Thomas wrote:
* Cristian Morales Vega (reddwarf@opensuse.org) [20120510 01:05]:
I am thinking about /usr/lib/gstreamer-0.10/gst-plugin-scanner, that apparently can't detect 32bit gstreamer plugins:
(gst-plugin-scanner:18379): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstcoreelements.so': /usr/lib/gstreamer-0.10/libgstcoreelements.so: wrong ELF class: ELFCLASS32
There is no real standard regarding libexecdir. It is defined in the GNU coding standard http://www.gnu.org/prep/standards/html_node/Directory-Variables.html
And that isn't very precise. My POV is that the wrong place was choosen for the plugins. They should either have used arch specific dirs below $(libexecdir)/@PACKAGE@ or (which is easier) used $(libdir)/@PACKAGE@.
All in all this is a discussion that should happen upstream since it's up to the upstream project to decide about the correct place in the presence of biarch platforms.
I think we generally avoid the use of libexecdir in favor of libdir. Richard. -- Richard Guenther <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Am 10.05.2012 12:33, schrieb Richard Guenther:
On Thu, 10 May 2012, Philipp Thomas wrote:
* Cristian Morales Vega (reddwarf@opensuse.org) [20120510 01:05]:
I am thinking about /usr/lib/gstreamer-0.10/gst-plugin-scanner, that apparently can't detect 32bit gstreamer plugins:
(gst-plugin-scanner:18379): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstcoreelements.so': /usr/lib/gstreamer-0.10/libgstcoreelements.so: wrong ELF class: ELFCLASS32
There is no real standard regarding libexecdir. It is defined in the GNU coding standard http://www.gnu.org/prep/standards/html_node/Directory-Variables.html
And that isn't very precise. My POV is that the wrong place was choosen for the plugins. They should either have used arch specific dirs below $(libexecdir)/@PACKAGE@ or (which is easier) used $(libdir)/@PACKAGE@.
All in all this is a discussion that should happen upstream since it's up to the upstream project to decide about the correct place in the presence of biarch platforms.
I think we generally avoid the use of libexecdir in favor of libdir.
libexecdir pointing to /usr/lib makes sense IMHO: Packages containing binaries which are not meant to be used directly by the user should place those into /usr/lib/PACKAGE AFAIK. There MUST NOT be any library there obviously. Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 10 May 2012 11:44, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
Am 10.05.2012 12:33, schrieb Richard Guenther:
On Thu, 10 May 2012, Philipp Thomas wrote:
* Cristian Morales Vega (reddwarf@opensuse.org) [20120510 01:05]:
I am thinking about /usr/lib/gstreamer-0.10/gst-plugin-scanner, that apparently can't detect 32bit gstreamer plugins:
(gst-plugin-scanner:18379): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstcoreelements.so': /usr/lib/gstreamer-0.10/libgstcoreelements.so: wrong ELF class: ELFCLASS32
There is no real standard regarding libexecdir. It is defined in the GNU coding standard http://www.gnu.org/prep/standards/html_node/Directory-Variables.html
And that isn't very precise. My POV is that the wrong place was choosen for the plugins. They should either have used arch specific dirs below $(libexecdir)/@PACKAGE@ or (which is easier) used $(libdir)/@PACKAGE@.
All in all this is a discussion that should happen upstream since it's up to the upstream project to decide about the correct place in the presence of biarch platforms.
I think we generally avoid the use of libexecdir in favor of libdir.
libexecdir pointing to /usr/lib makes sense IMHO:
Packages containing binaries which are not meant to be used directly by the user should place those into /usr/lib/PACKAGE AFAIK.
I would not be against it. But that's not what the GNU coding standards say and it would mean removing the only reason libexecdir exists. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 10 May 2012 11:33, Richard Guenther <rguenther@suse.de> wrote:
On Thu, 10 May 2012, Philipp Thomas wrote:
* Cristian Morales Vega (reddwarf@opensuse.org) [20120510 01:05]:
I am thinking about /usr/lib/gstreamer-0.10/gst-plugin-scanner, that apparently can't detect 32bit gstreamer plugins:
(gst-plugin-scanner:18379): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstcoreelements.so': /usr/lib/gstreamer-0.10/libgstcoreelements.so: wrong ELF class: ELFCLASS32
There is no real standard regarding libexecdir. It is defined in the GNU coding standard http://www.gnu.org/prep/standards/html_node/Directory-Variables.html
And that isn't very precise. My POV is that the wrong place was choosen for the plugins. They should either have used arch specific dirs below $(libexecdir)/@PACKAGE@ or (which is easier) used $(libdir)/@PACKAGE@.
All in all this is a discussion that should happen upstream since it's up to the upstream project to decide about the correct place in the presence of biarch platforms.
I think we generally avoid the use of libexecdir in favor of libdir.
If we think libdir is what should be used... let's define libexecdir as libdir! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 10 May 2012 11:26, Philipp Thomas <pth@suse.de> wrote:
* Cristian Morales Vega (reddwarf@opensuse.org) [20120510 01:05]:
I am thinking about /usr/lib/gstreamer-0.10/gst-plugin-scanner, that apparently can't detect 32bit gstreamer plugins:
(gst-plugin-scanner:18379): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstcoreelements.so': /usr/lib/gstreamer-0.10/libgstcoreelements.so: wrong ELF class: ELFCLASS32
There is no real standard regarding libexecdir. It is defined in the GNU coding standard http://www.gnu.org/prep/standards/html_node/Directory-Variables.html
And that isn't very precise. My POV is that the wrong place was choosen for the plugins. They should either have used arch specific dirs below $(libexecdir)/@PACKAGE@ or (which is easier) used $(libdir)/@PACKAGE@.
The plugins are installed in $(libdir)/@PACKAGE@. Only gst-plugin-scanner is installed in $(libexecdir)/@PACKAGE@. And that's exactly what the GNU coding standards say since gst-plugin-scanner is an "executable program to be run by other programs rather than by users". In fact about libdir they say "Do not install executables here, they probably ought to go in ‘$(libexecdir)’ instead". You can't blame gstreamer here for using libexec.
All in all this is a discussion that should happen upstream since it's up to the upstream project to decide about the correct place in the presence of biarch platforms.
I don't know how to argue with upstream that they should use libdir for gst-plugin-scanner when the GNU coding standards so clearly say they should use libexecdir and even explicitly says they should not use libdir. The same problem would happen with the plugins if we weren't defining _libdir as /usr/lib64. We are the ones behaving in inconsistent ways. But I don't think this is gstreamer specific. We should talk with upstream, but that upstream should be RPM. I just wanted to know if there is any good cause for things being the way they are now. And if we should patch rpm or gstreamer. But really, any patch to the gstreamer package probably is going to stay in openSUSE. I don't think gstreamer will want to change this. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Cristian Morales Vega (reddwarf@opensuse.org) [20120510 12:53]:
(gst-plugin-scanner:18379): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstcoreelements.so': /usr/lib/gstreamer-0.10/libgstcoreelements.so: wrong ELF class: ELFCLASS32
The plugins are installed in $(libdir)/@PACKAGE@. Only gst-plugin-scanner is installed in $(libexecdir)/@PACKAGE@.
Then its looking in the wrong place aka is buggy coded! A 32 bit binary *must* only search in /usr/lib/gstreamer and the 64 bit binary *must* only look in /usr/lib64. I'd say this is a clear bug in gst-plugin-scanner. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 10 May 2012 12:07, Philipp Thomas <pth@suse.de> wrote:
* Cristian Morales Vega (reddwarf@opensuse.org) [20120510 12:53]:
(gst-plugin-scanner:18379): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstcoreelements.so': /usr/lib/gstreamer-0.10/libgstcoreelements.so: wrong ELF class: ELFCLASS32
The plugins are installed in $(libdir)/@PACKAGE@. Only gst-plugin-scanner is installed in $(libexecdir)/@PACKAGE@.
Then its looking in the wrong place aka is buggy coded! A 32 bit binary *must* only search in /usr/lib/gstreamer and the 64 bit binary *must* only look in /usr/lib64. I'd say this is a clear bug in gst-plugin-scanner.
Agreed. It's a bit inefficient for the 64 bit binary searching in /usr/lib/gstreamer. I will look into it. But that's unrelated to the libexecdir thing. If you want a 32 bit binary that only searches in /usr/lib/gstreamer and a 64 binary that only searches in /usr/lib64/gstreamer... you still need *two* places to put them in. They are executables, so they must be installed in "libexecdir", but libexecdir is /usr/lib for both i586 and x86-64. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 10 May 2012, Cristian Morales Vega wrote:
On 10 May 2012 12:07, Philipp Thomas <pth@suse.de> wrote:
* Cristian Morales Vega (reddwarf@opensuse.org) [20120510 12:53]:
(gst-plugin-scanner:18379): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstcoreelements.so': /usr/lib/gstreamer-0.10/libgstcoreelements.so: wrong ELF class: ELFCLASS32
The plugins are installed in $(libdir)/@PACKAGE@. Only gst-plugin-scanner is installed in $(libexecdir)/@PACKAGE@.
Then its looking in the wrong place aka is buggy coded! A 32 bit binary *must* only search in /usr/lib/gstreamer and the 64 bit binary *must* only look in /usr/lib64. I'd say this is a clear bug in gst-plugin-scanner.
Agreed. It's a bit inefficient for the 64 bit binary searching in /usr/lib/gstreamer. I will look into it. But that's unrelated to the libexecdir thing. If you want a 32 bit binary that only searches in /usr/lib/gstreamer and a 64 binary that only searches in /usr/lib64/gstreamer... you still need *two* places to put them in. They are executables, so they must be installed in "libexecdir", but libexecdir is /usr/lib for both i586 and x86-64.
Binaries are usually not "multilibbed" and if they are they need distinctive names. For example we have 'gdb' and 'gdb64' on powerpc, both live in /usr/bin. Richard. -- Richard Guenther <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
On 10 May 2012 13:06, Richard Guenther <rguenther@suse.de> wrote:
On Thu, 10 May 2012, Cristian Morales Vega wrote:
On 10 May 2012 12:07, Philipp Thomas <pth@suse.de> wrote:
* Cristian Morales Vega (reddwarf@opensuse.org) [20120510 12:53]:
(gst-plugin-scanner:18379): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstcoreelements.so': /usr/lib/gstreamer-0.10/libgstcoreelements.so: wrong ELF class: ELFCLASS32
The plugins are installed in $(libdir)/@PACKAGE@. Only gst-plugin-scanner is installed in $(libexecdir)/@PACKAGE@.
Then its looking in the wrong place aka is buggy coded! A 32 bit binary *must* only search in /usr/lib/gstreamer and the 64 bit binary *must* only look in /usr/lib64. I'd say this is a clear bug in gst-plugin-scanner.
Agreed. It's a bit inefficient for the 64 bit binary searching in /usr/lib/gstreamer. I will look into it. But that's unrelated to the libexecdir thing. If you want a 32 bit binary that only searches in /usr/lib/gstreamer and a 64 binary that only searches in /usr/lib64/gstreamer... you still need *two* places to put them in. They are executables, so they must be installed in "libexecdir", but libexecdir is /usr/lib for both i586 and x86-64.
Binaries are usually not "multilibbed" and if they are they need distinctive names. For example we have 'gdb' and 'gdb64' on powerpc, both live in /usr/bin.
Are usually not "multilibbed" as in "this gstreamer case is so specific that is better to patch it than change libexecdir in rpm"? Really, no idea... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Cristian Morales Vega (reddwarf@opensuse.org) [20120510 14:09]:
Are usually not "multilibbed" as in "this gstreamer case is so specific that is better to patch it than change libexecdir in rpm"?
It's simple. In all cases it's up to upstream to fix it. Be it by naming the binaries according to their bitness, having one binary that only looks into the right directory or by using arch dependent directories in libexecdir. Libexecdir as it is doesn't need cahnges. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Cristian Morales Vega (reddwarf@opensuse.org) [20120510 13:35]:
only searches in /usr/lib64/gstreamer... you still need *two* places to put them in. They are executables, so they must be installed in "libexecdir", but libexecdir is /usr/lib for both i586 and x86-64.
Only if you name me a real reason for that. 586 packages will replace x64 packages and vice versa as long as they don't contain libraries. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (4)
-
Cristian Morales Vega -
Philipp Thomas -
Richard Guenther -
Wolfgang Rosenauer