When I try to emerge vmware-server on my amd64 system, portage comes up with [ebuild N ] x11-misc/util-macros-1.1.0 USE="-debug" 0 kB [ebuild N ] app-emulation/emul-linux-x86-baselibs-10.2 24,670 kB [ebuild N ] dev-perl/XML-Parser-2.34 225 kB [ebuild N ] sys-apps/xinetd-2.3.14 USE="perl tcpd" 295 kB [ebuild N ] x11-proto/xproto-7.0.7 USE="-debug" 131 kB [ebuild N ] dev-util/intltool-0.35.0 127 kB [ebuild N ] x11-proto/kbproto-1.0.3 USE="-debug" 57 kB [ebuild N ] x11-proto/xextproto-7.0.2 USE="-debug" 67 kB [ebuild N ] x11-proto/xf86bigfontproto-1.1.2 USE="-debug" 37 kB [ebuild N ] x11-proto/inputproto-1.3.2 USE="-debug" 46 kB [ebuild N ] x11-proto/bigreqsproto-1.0.2 USE="-debug" 36 kB [ebuild N ] x11-proto/xcmiscproto-1.1.2 USE="-debug" 36 kB [ebuild N ] x11-libs/xtrans-1.0.1 USE="-debug" 90 kB [ebuild N ] x11-misc/shared-mime-info-0.19 582 kB [ebuild N ] x11-libs/libXau-1.0.2 USE="-debug" 215 kB [ebuild N ] x11-libs/libXdmcp-1.0.1 USE="-debug" 227 kB [ebuild N ] x11-libs/libX11-1.0.3 USE="-debug -ipv6" 1,416 kB [ebuild N ] app-emulation/vmware-modules-1.0.0.15-r1 291 kB [ebuild N ] app-emulation/emul-linux-x86-xlibs-10.0 USE="-opengl" 20,538 kB [ebuild N ] app-emulation/emul-linux-x86-gtklibs-10.0-r1 USE="-qt3" 11,843 kB [ebuild N ] app-emulation/vmware-server-1.0.2.39867 104,652 kB This doesn't make sense. The package emul-linux-x86-xlib contains all the X11 libraries vmware server gets linked against. So why is it also trying to install the 64-bit versions? OTOH, it's not clear why vmware is being rigged to link against 32-bit libraries to begin with. ---------- emerge info provided below Portage 2.1.2.2 (default-linux/amd64/2006.1/server, gcc-4.1.2, glibc-2.5-r1, 2.6.20-gentoo x86_64) ================================================================= System uname: 2.6.20-gentoo x86_64 AMD Opteron(tm) Processor 250 Gentoo Base System release 1.12.10 Timestamp of tree: Mon, 09 Apr 2007 20:00:08 +0000 dev-java/java-config: 1.3.7, 2.0.31-r5 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.20-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=opteron -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/php/apache1-php4/ext-active/ /etc/php/apache2-php4/ext-active/ /etc/php/cgi-php4/ext-active/ /etc/php/cli-php4/ext-active/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=opteron -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LINGUAS="en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/config/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 apache2 cli cracklib crypt dri gdbm gpm iconv innodb libg++ lm_sensors logrotate mailwrapper mysql ncurses nls nolvm1 nptl nptlonly pam pcre perl ppds pppd readline reflection sensord session snmp spl ssl tcpd truetype unicode vhosts xml zlib" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
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.
