On 07/31/2014 02:18 PM, David Haller wrote:
Hello,
On Thu, 31 Jul 2014, Anton Aylward wrote:
On 07/31/2014 11:31 AM, Cristian Rodríguez wrote:
El 31/07/14 a las #4, Anton Aylward escribió:
So, right now, given that I'm not using wayland, and as you say probably won't be for some while, can I simply delete these?
You can't. unless you want a system without X or a desktop environment. Currently removing the first package triggers removal of ~400 packages.
WTF! Why? Is this a real dependency that the code has to be there, even if we're not using Wayland, or is this simply "yes another stupid packaging issue"?
It's a matter of dynamic linking. You can either link to a lib, then you'll need that lib to be installed, or you don't. The only alternative is dynamic linking (cue plugins for e.g. vlc), but that has its own traps.
I guess, with libwayland* (as with most other libs) it is just not possible to load these libs dynamically via libdl. So, you have to link to these libs, thus you need to install the libs. AFAIR they won't get actually loaded into memory until actually used.
If you do not install all linked-to libs, you'll just get a linker error, when you try to run the program.
You'll have to look closely at the dependencies, some you can ignore (explicitly set deps in a "aggregating" package (see below)), some you can not. E.g.:
$ rpm -q --requires kdebase4-runtime | grep soprano libsoprano.so.4()(64bit) libsopranoserver.so.1()(64bit) soprano-backend-redland $ rpm -qa '*soprano*' libsoprano4-2.8.0-122.5.x86_64
"libsoprano.so.4()(64bit)" is a real dependency of at least one program/lib packaged in kdebase4-runtime, but "soprano-backend-redland" is a "manual explicit" dep, which I can ignore as I do not intend to ever use soprano. The programs using soprano will still run, as libsoprano* are installed, but their soprano-functionality won't.
Same with wayland. You'll need the libwayland*, but not wayland itself and you can ignore manual deps on it if you do now want to use wayland.
Actually: many such "explicit manual" deps could be "Recommends", or programs needing a lib could be split out into a seperate package. Vlc (vlc-noX, vlc (uses gtk), vlc-qt, libvlc*) is a prime example how it can be done. But the program(s) need to be seperatable as vlc is too.
Each of those packages contains just the one bianry and link. rpm -ql libwayland-client0-1.2.1-1.1.x86_64 \ libwayland-cursor0-1.2.1-1.1.x86_64 \ libwayland-server0-1.2.1-1.1.x86_64 \ libwayland-egl1-10.2.4-381.1.x86_64 /usr/lib64/libwayland-client.so.0 /usr/lib64/libwayland-client.so.0.1.0 /usr/lib64/libwayland-cursor.so.0 /usr/lib64/libwayland-cursor.so.0.0.0 /usr/lib64/libwayland-server.so.0 /usr/lib64/libwayland-server.so.0.1.0 /usr/lib64/libwayland-egl.so.1 /usr/lib64/libwayland-egl.so.1.0.0 So that eliminates the possibility that there is some other function in the package. Those like like dynamic libraries. Let me run 'file' on each...) /usr/lib64/libwayland-client.so.0: symbolic link to `libwayland-client.so.0.1.0' /usr/lib64/libwayland-client.so.0.1.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=e23c66009f0244b0941f667292532428a4526115, stripped /usr/lib64/libwayland-cursor.so.0: symbolic link to `libwayland-cursor.so.0.0.0' /usr/lib64/libwayland-cursor.so.0.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=fb03ad69713143387df0e2c4b0b32c0647045c74, stripped /usr/lib64/libwayland-server.so.0: symbolic link to `libwayland-server.so.0.1.0' /usr/lib64/libwayland-server.so.0.1.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=2b279857315e09f5bc23acbf49eea0415727680e, stripped /usr/lib64/libwayland-egl.so.1: symbolic link to `libwayland-egl.so.1.0.0' /usr/lib64/libwayland-egl.so.1.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=8261041ceddb470d9c2167361eadfa307e37088d, stripped So yes they are. So lets see what they call ldd /usr/lib64/libwayland-client.so.0.1.0 linux-vdso.so.1 (0x00007fff1133f000) libffi.so.4 => /usr/lib64/libffi.so.4 (0x00007f3d496d9000) librt.so.1 => /lib64/librt.so.1 (0x00007f3d494d1000) libc.so.6 => /lib64/libc.so.6 (0x00007f3d49121000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3d48f03000) /lib64/ld-linux-x86-64.so.2 (0x00007f3d49b12000) ldd /usr/lib/libffi.so.4 linux-gate.so.1 (0xf76f3000) libc.so.6 => /lib/libc.so.6 (0xf7516000) /lib/ld-linux.so.2 (0xf76f4000) ldd /usr/lib64/librt.so linux-vdso.so.1 (0x00007fff335fe000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f693282d000) libc.so.6 => /lib64/libc.so.6 (0x00007f693247e000) /lib64/ld-linux-x86-64.so.2 (0x00007f6932a4b000) All that is pretty vanilla., so there is nothing further down in the call tree that would cause the dependency. Therefore it must be something in those hundreds of packages that is calling The following 349 packages are going to be REMOVED: akonadi akonadi-runtime apper apper-lang appmenu-qt ark audex [....] DirectFB DirectFB-Mesa dolphin [....] xf86-input-evdev xf86-input-joystick xf86-input-keyboard xf86-input-mouse xf86-input-synaptics xf86-input-vmmouse xf86-input-void xf86-input-wacom xf86-video-fbdev xf86-video-modesetting xf86-video-nouveau xf86-video-nv xf86-video-vesa xorg-x11-driver-input xorg-x11-driver-video xorg-x11-server xscreensaver-data-extra yast2-control-center yast2-control-center-qt Now in a couple of years I can see all those making use of Wayland at the lower levels of the stack, or some of them. I hope we're not running X on top of Wayland; I thought the idea was to shrink the stack. But why now? Somewhere in all that tree something calls calls on of the leyland functions: http://wayland.freedesktop.org/docs/html/chap-Library.html WHY? This isn't Wayland we're running What's really going on? -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org