| Summary: | app-emulation/emul-linux-x86-xlibs depends on x11-libs/libX11 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Maurice Volaski <mvolaski> |
| Component: | New packages | Assignee: | AMD64 Project <amd64> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Maurice Volaski
2007-04-10 19:01:57 UTC
Because app-emulation/emul-linux-x86-xlibs depends on x11-libs/libX11; this has nothing to do w/ vmware-server ebuild. Oh, then why is that the case? I just ran ldd for every library in this package and I don't see any references to any 64-bit libX11 libraries. It seems to be self-contained. There's some shared data in /usr/share/X11. If both were providing this path they would collide, so we decided that libX11 should provide them and the emul-package should depend on it, so the dependency is correct and there's nothing to do IMO. I don't entirely follow this rationale. x11 libs are already split across a dozen packages. And with the exception of this shared data, the emul package doesn't need any of them. So with all the effort to break up x11, why not break out the shared stuff into its own package, say, an x11-libs/x11-shared-data? Both x11 libs and the emul package will depend on that package. In the end, 64-bit x11 has one more package to install, which it has to install anyway, and the 32-bit version just has one dependency rather than a dozen! Please see if that is doable. I am installing vmware, which needs and can only use the 32-bit x11 libs. It doesn't really need any of the 64-bit x11 stuff. I'm sorry, but I've never heard of a system where you wanted the emul xlibs but not the native ones. We try to limit ourselves to reasonably common cases. I don't want x11. I prefer the command-line and just seem extraneous to install X. I want to run vmware-server. For some reason, the vmware executable itself is linked against 32-bit x11 libraries. sudo ldd vmware-vmx linux-gate.so.1 => (0xffffe000) libm.so.6 => /lib32/libm.so.6 (0xf7f57000) libdl.so.2 => /lib32/libdl.so.2 (0xf7f53000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7f3c000) libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7e51000) libXtst.so.6 => /usr/lib32/libXtst.so.6 (0xf7e4b000) libXext.so.6 => /usr/lib32/libXext.so.6 (0xf7e3d000) libXt.so.6 => /usr/lib32/libXt.so.6 (0xf7dee000) libICE.so.6 => /usr/lib32/libICE.so.6 (0xf7dd7000) libSM.so.6 => /usr/lib32/libSM.so.6 (0xf7dce000) libXrender.so.1 => /usr/lib32/libXrender.so.1 (0xf7dc6000) libz.so.1 => /lib32/libz.so.1 (0xf7db3000) libc.so.6 => /lib32/libc.so.6 (0xf7c8d000) /lib/ld-linux.so.2 (0xf7f8c000) libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7c8a000) libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7c85000) I don't know why it needs them, but it apparently does. Even better would be a specially prepared vmware-x11-libs ebuild. the easy solution to your problem is install the emul libs with --nodeps and if you want emerge -uD world to work, you can put to put x11-libs/libX11 in package.provided (In reply to comment #6) > I don't know why it needs them, but it apparently does. Even better would be a > specially prepared vmware-x11-libs ebuild. No chance. We (the VMware team) don't want to maintain such a package. If you feel there's a problem here, feel free to contact VMware and get them to not require libX11 with their next release. Our X packages are not split arbitrarily, as you suggest doing, but are split to be inline with what upstream is doing. Again, if you think the libX11 package needs to be split, have it split upstream and we'll pick up the changes naturally. Changing resolution to UPSTREAM since if any changes were to be made, they would need to be made there. I'm actually surprised this wasn't left as "invalid". OTOH, as far as the emul library is concerned, it appears to be a Gentoo's creation, so I don't see how there could ever be an upstream change that would result in the /usr/share stuff split into a different package. The only upstream change, then I guess, would be for vmware not to link against X. Does anyone know why it needs X? It currently uses libXpm, for sure. It uses X mostly for the remote capabilities. Also, as I said, the change could be either VMware removing the dependency, or X.Org changing libX11 to provide the /usr/share components outside of libX11 in another package. Either solution would work and give us something to work with. As things are now, the dependencies are actually correct for what we've been provided, and it isn't likely we'll be changing this for a single package. |
