FS#33848 - [gst-plugins-bad] wayland dependency?

Attached to Project: Arch Linux
Opened by Jente (Unia) - Wednesday, 13 February 2013, 22:01 GMT
Last edited by Allan McRae (Allan) - Thursday, 14 February 2013, 03:53 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


Since the last update, gst-plugins-bad depends on Wayland. In this[1] forum topic, someone has recompiled gst-plugins-bad from ABS and everything works fine with Wayland.

In that case, I think Wayland should be moved to an optdepend. Unless you have a reason to add it as a dependency, that we do not know about?

I'm curious what you think about this.


[1] https://bbs.archlinux.org/viewtopic.php?id=158064
This task depends upon

Closed by  Allan McRae (Allan)
Thursday, 14 February 2013, 03:53 GMT
Reason for closing:  Not a bug
Comment by Allan McRae (Allan) - Wednesday, 13 February 2013, 22:54 GMT
Does installing the package from [extra] and removing wayland from your system make it still work? That is required for optdepends...
Comment by Armin K. (Krejzi) - Thursday, 14 February 2013, 01:01 GMT
I do not see the problem, really. It was me who requested Wayland plugin to be enabled.

Yes, it can be listed as optdepends, /usr/lib/gstreamer-1.0/libgstwaylandsink.so is only plugin that links to libwayland.

As soon as Cairo and Mesa 9.0.2-2 are moved to extra, everything will pull wayland that uses cairo or Mesa. Having wayland plugin installed should not harm anything else. If that's the case, report the bug to gstreamer upstream. I didn't encounter any problems and I have gstreamer wayland plugin installed for a while.

Also, wayland is just a library. It isn't even a megabyte - why bother? Cairo will get pulled by GStreamer anyways.
Comment by Mark E. Lee (bluerider) - Thursday, 14 February 2013, 02:15 GMT
Cairo and mesa in testing don't require wayland. It is libegl that requires wayland. Also, looking at the PKGBUILD for libegl, it seems that wayland should be an optional dependency for libegl as well. The library should work without wayland.
Comment by Armin K. (Krejzi) - Thursday, 14 February 2013, 03:11 GMT

libegl *requires* wayland, since it is linked to it. Issue ldd /usr/lib/libEGL.so and you'll notice the two lines:

libwayland-client.so.0 => /usr/lib/libwayland-client.so.0 (0x00007ff0e4474000)
libwayland-server.so.0 => /usr/lib/libwayland-server.so.0 (0x00007ff0e4263000)

On the other hand, Cairo has EGL backend enabled and thus is directly linked to libEGL.so, which means it also depends on libwayland-whatever.so.0.

Don't believe me? Issue ldd /usr/lib/libcairo.so.2

$ ldd /usr/lib/libcairo.so
linux-vdso.so.1 (0x00007fffa5fff000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f8699ee3000)
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x00007f8699c4c000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f8699a12000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f8699774000)
libEGL.so.1 => /usr/lib/libEGL.so.1 (0x00007f8699552000)
libwayland-client.so.0 => /usr/lib/libwayland-client.so.0 (0x00007f8696825000)
libwayland-server.so.0 => /usr/lib/libwayland-server.so.0 (0x00007f8696614000)
Comment by Mark E. Lee (bluerider) - Thursday, 14 February 2013, 03:22 GMT
Here's the output of my `ldd /usr/lib/libEGL.so`:
linux-vdso.so.1 (0x00007fff3d7ff000)
libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0x00007f1034ebf000)
libxcb-dri2.so.0 => /usr/lib/libxcb-dri2.so.0 (0x00007f1034cba000)
libxcb-xfixes.so.0 => /usr/lib/libxcb-xfixes.so.0 (0x00007f1034ab3000)
libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x00007f10348a8000)
libxcb-shape.so.0 => /usr/lib/libxcb-shape.so.0 (0x00007f10346a4000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f1034485000)
libgbm.so.1 => /usr/lib/libgbm.so.1 (0x00007f103427e000)
libglapi.so.0 => /usr/lib/libglapi.so.0 (0x00007f1034058000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f1033d1f000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f1033b02000)
libudev.so.1 => /usr/lib/libudev.so.1 (0x00007f10338f1000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007f10336e9000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f10334e4000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007f10332d8000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f1032f2b000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f1032d26000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f1032b20000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f103530d000)
libsystemd-daemon.so.0 => /usr/lib/libsystemd-daemon.so.0 (0x00007f103291c000)

No mention of wayland anywhere. Also, if you check out the MESA EGL site : http://www.mesa3d.org/egl.html
There's no mention of wayland. I know it supports it, but that doesn't mean it needs it.

Why don't you try compiling the packages without wayland installed (and without wayland in the depends lines in the PKGBUILDs) and see if you still need wayland.
Comment by Armin K. (Krejzi) - Thursday, 14 February 2013, 03:24 GMT
Dude, why is it a problem to understand that Archlinux by default depends on Wayland? libegl 9.0.2-2 from *repositories* NEEDS it - it is in [testing] repository right now.

It's not Mesa that *needs* it, it's Wayland integration that needs it - Weston and toolkits, too. But for them to work, support in Cairo and Mesa is *necesary*
Comment by Mark E. Lee (bluerider) - Thursday, 14 February 2013, 03:30 GMT
In a previous post, I already indicated that libegl should have wayland as an optional dependency as well. Libegl 9.0.2-2 is still in testing as well. Is it difficult to understand that not all users may not want to jump on the wayland bandwagon until it is apparent wayland is stable?
Comment by Allan McRae (Allan) - Thursday, 14 February 2013, 03:39 GMT
libegl can not have wayland as an optional dependency:

> readelf -d /usr/lib/libEGL.so.1.0.0
0x00000001 (NEEDED) Shared library: [libwayland-client.so.0]
0x00000001 (NEEDED) Shared library: [libwayland-server.so.0]

wayland linked in so it must be on your system if libegl is. Whether it actually is used or not is another story...
Comment by Mark E. Lee (bluerider) - Thursday, 14 February 2013, 03:48 GMT
My output doesn't grab any wayland dependencies once again. Perhaps two packages should be maintained, one that has wayland support compiled, and one that doesn't.
Comment by Allan McRae (Allan) - Thursday, 14 February 2013, 03:51 GMT
You are not using [testing] where it IS compiled against wayland...

And no, two versions of the package will not be maintained officially. You are free to create "...-nowayland" packages in the AUR, just like people did with libpulse etc (lets see if that lasts for more than a few weeks...). Only one package will be maintained officially.