On 07/31/2014 05:03 PM, Cristian Rodríguez wrote:
El 31/07/14 a las #4, Anton Aylward escribió:
On 07/31/2014 11:55 AM, Cristian Rodríguez wrote:
El 31/07/14 a las #4, Anton Aylward escribió:
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 is a real dependency.. code is using the API provided by those libraries.. of course it is not active unless you are running wayland.
Eh?
There's something that doesn't seem right in that explanation.
If Wayland isn't there to make use of the APIs, *and* the APIs are encapsulated in these libraries, then these libraries should be removable if Wayland isn't around to make use of them. Think about the call tree.
That's not how things work..libraries are linked, have a dependency at the binary level, what you are proposing is somehow similar to making the apps use dlopen() to load the libraries on demand.. that ain't gonna work well unfortunately.
Re reading what I wrote I can see how you might think that I mean that the search for the libraries was carried out at call-time rather than earlier. I realise that the link-loader (or should it be called a load-linker) has 'compile time" and execute/load time components. The compile linkage identifies the required libraries; the link-loader finds them and resolves the links at load time by reference to LD_LIBRARY_PATH thank you ld.so and ld-linux.so. Linux wasn't the first to do this :-)
I 'll let you just the tip of the iceberg.. RPM has no clue how to handle dlopen()'ed libraries, therefore dependency and version handling is let to the packager..and is gonna break everytime the library version changes..plus.. you are requesting this to be done in a component which is under heavy development..its api may or may not be stable..and down the drain we go...
You are correct in the above but I'm not sure what relevance it has with what I'm trying to establish. Right now we are not using Wayland. We don't need the Wayland libraries I mentioned, the Wayland functions at http://wayland.freedesktop.org/docs/html/chap-Library.html So long as the KDE components don't make direct calls to X, so long as they use the Qt library, then this should work Before using Wayland, have LD_LIBRARY_PATH direct the runtime link-loader to libraries that have Qt making calls to the X.org API When Wetland is being used have the LD_LIBRARY_PATH direct to the Wayland API. Right now it seems that the Wayland libraries such as -client0 are somehow involved. I don't have time to trace though source of the 300+ items and follow the call trees to see if they do in fact make calls to any of those functions in /usr/lib64/libwayland-client.so or if this is a packaging issue. If we have current high level applications calling Wayland I'm very curious as to why, if, as you say, Wayland isn't stable and isn't going to be around for a couple of years. -- The major advances in civilization are processes that all but wreck the societies in which they occur. -- A.N. Whitehead -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org