On 07/31/2014 06:48 PM, David Haller wrote:
You've got that backwards. There is stuff that needs those libs, because it links to it. Which, as I tried to explain, does not neccessarily mean, those libs are actually used (or even loaded from the disks rotating rust (or flash)). AFAIK ld mmap's the libs (i.e. allocates address space), but they only get actually loaded from DRR/Flash when they're used.
Therefore it must be something in those hundreds of packages that is calling
The following 349 packages are going to be REMOVED: [..]
Linked to != actually calling in use!
I agree with that last line but don't think I have this backwards. Let me explain it in a different manner then. I can take the old "hello World" C program that just uses STDIO but when I package it I do two things. The first is that I tell the build process to include the un-needed libk5crypto.so.3. The second is that I tell the RPM build that the package OpenPrintingPPDs-postscript-4.0.0-21.1.2.noarch is a required dependency. Both are really irrelevant. So when zypper - or yast if you want - tried to install AntonsHello-0.1.x86_64 its going to make sure that two other packages are installed as well. But code wise, neither of them are really needed. They are an artefact of the way I defined the what was to be required. Now when, in due course, I use the CLI to run this program the link-loader will see that libc is needed (for the STDIO stuff) and also that libk5crypto.so.3 should be loaded. When the code runs I see "hello world" appear. The functions in libk5crypto.so.3 are never called. This illustrates the "Linked to != actually calling in use!" point. Next I go away and set up a build service and my own repository and make a copy of .... Oh, say DirectFB-Mesa-1.6.3-4.1.3.x86_64 I make no changes to to code, I just add to the configuration a dependency on AntonsHello-0.1.x86_64. Yes it completely irrelevant, but so what. Until recently the 'tar' package included 'rmt' because once upon a time tar was a Tape Archiver and so was always used with magnetic tape. Conversely to get the tape driver you ended up with tar whether you wanted it or not. I recall we discussed that here some years ago. I'm sure there are many idiotic and unnecessary dependencies like this. Now having illustrated the "Linked to != actually calling in use!" point lets go back to the wayland-client package and library. I checked the downstream because there were hundreds of items in the upstream. Suppose I were to pick one. It might not be a good illustration adn we start playing yes-but games, but suppose it was a "good one". I run it under the debugger and I find that there are never calls to anything in the wayland-client. So, the counter argument goes, it was there but never called because we aren't using wayland. It seems like a circular argument to me, but there was a tool I used back in the days of SunOS and the old ATT 3B machines that you could apply to a pile of source and libraries and binaries and it figured out the complete call tree of the program. It was used for documenting archaic code and figuring out if changing something would impact ... Whatever. Sort of like the Gnu 'cflow' program but could handle binaries as well as source. Applying that to my HellowWorld binary would make it clear that there were no calls to any functions in libk5crypto.so.3. So I'd love to apply it to all the programs in the 300+ packages and see it any actually did call the functions in libwayland-client0. My suspicion is that they don't. Back to the "Linked to != actually calling in use!" So why is it being linked in ?
There may be 349 packages (indirectly) linking to libwayland*, but
I suspect that there are about 300 in the "indirectly" category; after all, what zypper has returned is the flattened tree. Say there are just 49 packages that have a dependency, whether or not they have a program that links (but never calls). There is still a dependency tree at the package level.
any of them actually _using_ that interface is probably nil. Yet.
We are in agreement, but I have my reservations about the "yet" being the best way of doing things. If we have X running on top of Wayland that all we've done is slide an extra layer in at the bottom of the stack. I don't see an advantage in that. However if we have an either/or situation where there is a set of Qt libraries supporting KDE which makes use of the X server and separate set of libraries that make use of the Wayland server (and similar for GTK) and so we have a Wayland stack that better suits modern GPUs without all the overhead of the X protocols hat never gets used. As I said, LD_LIBRARY_PATH can take care of this.
I don't know Wayland. I don't see its use (yet). I'm uninformed about it. But I know how the ELF linking works. So there might be some app somewhere amongst those 349 packages, that actually uses libwayland* when you start it and do stuff, but I guess most don't. Yet. I've not really an opinion on Wayland. But guessing from history, I'll hate it. Probably with a vengeance. Not as much as systemd, I assume. That's hard^Wimpossible to exceed.
Let me put it this way. Familiarity doesn't mean its better. The automobile carburettor ended up being quite complicated with all the stuff that had been piled on the original concept to deal with starting the engine, different weather conditions resulting in different air pressure (and driving up mountains and across deserts), humidity, engine temperature, air temperature, and more. When petrol injection came along it confused many auto mechanics because it was new even though, by comparison it was simpler. I had a European car with PI and so long as I took it to a 'factory trained' guy who had migrated here it was fine. He died and a regular mechanic screwed it up. Now PI is considered the norm. Familiarity. The X protocol was a piece of academia which, for the lack of any alternative, became adopted. Perhaps modern GPUs have been driven by he needs of Microsoft, but X always had cruft that no-one used, and the way it was 'device independent' made it very complicated. I've read that Wayland can support X, but my reaction is "Why?"
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.
AFAIK, Wayland is supposed to replace X11. I.e. be a X12 of some sort.
That would make sense if we weren't to un X on top of Wayland as I've read about. Reducing the depth of the stack, as I say, implementing Qt and GTK directly on Wayland since they are the "HLL" in which KDE and Gnome/LXDE/xfce are written, makes sense. Adding another layer to the stack doesn't.
But why now?
Prepping for the switch to Wayland would be my guess.
That doens't make sense to me.
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?
http://wayland.freedesktop.org/docs/html/chap-Introduction.html#sect-Motivat... ff.
I assume.
Lots of words but its a bit confused. Mind you, on the next age there's the lovely bit: X will always be relevant, in the same way Fortran compilers and VRML browsers are, but it’s time that we think about moving it out of the critical path and provide it as an optional component for legacy applications. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- The chief forms of beauty are order and symmetry and definiteness, which the mathematical sciences demonstrate in a special degree. -- Aristotle (384-322 B.C.), Metaphysics -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org