With the new gentoo-macos-20040726 installation script (which includes collision detection), glib refuses to install, with the error message "existing file /usr/lib/charset.alias is not owned by this package". Since /usr/lib/charset.alias is the only file in conflict (at least on my machine), it's safe to work around this by temporarily turning off collision detection, but that's not a viable long-term solution. File contents before glib installation, and what glib would modify: localhost:~ rmunn$ cat /usr/lib/charset.alias # This file contains a table of character encoding aliases, # suitable for operating system 'darwin7.0'. # It was automatically generated from config.charset. # Packages using this file: localhost:~ rmunn$ cat /var/tmp/portage/glib-2.4.4/image/usr/lib/charset.alias # This file contains a table of character encoding aliases, # suitable for operating system 'darwin'. # It was automatically generated from config.charset. # Packages using this file: glib localhost:~ rmunn$ Note that only comments have changed. Reproducible: Always Steps to Reproduce: 1. emerge -av glib 2. 3. Actual Results: Compilation succeeds, but installation fails. Expected Results: Perhaps the /usr/lib/charset.alias should be handled with CONFIG_PROTECT the way the /etc directory is protected? I don't know what packages want to modify this file, so I don't know if that would be a workable solution. But the collision-detection feature needs to handle this file better somehow. localhost:~ rmunn$ emerge info !!! Using `which gcc` to gcc locate version, this may break !!! DISTCC, installing gcc-config and setting your current gcc !!! profile will fix this Portage 20040726 (default-macos-10.3, gcc-3.3, unavailable, 7.4.0 Power Macintosh powerpc) ================================================================= System uname: 7.4.0 Power Macintosh powerpc macos-20040726 distcc 2.0.1-zeroconf powerpc-apple-darwin7.0 (protocol 1) (default port 3632) [disabled] Autoconf: Automake: Binutils: ACCEPT_KEYWORDS="macos" AUTOCLEAN="yes" CFLAGS="-O2 -pipe" CHOST="powerpc-apple-darwin" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="collision-protect cvs keepwork" GENTOO_MIRRORS="http://gentoo.osuosl.org/" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="macos"
Oops, left hardware platform set to "All" by mistake. Changing it to "PPC", since there isn't a "macos" choice in the dropdown. (I think we should distinguish ppc from macos in the hardware dropdown, since we distinguish them in the ebuild keywords).
This should work just fine if you do an emerge sync and then try again. Later installers will either (a) include a more updated portage snapshot, or (b) not carry a portage snapshot at all, and download it on the fly. Please confirm that the problem is resolved, and close the bug.
I personally vote for not including a snapshot at all, primarily due to Installer.app's inefficient handling of large numbers of files.
Yes, the most recent ebuilds resolve this bug.
Reopening this bug, because now it's failing again. I don't know what changed in the glib-2.4.4 ebuild since last month, but something clearly did. See also bug 62416: the same problem seems to exist in glib-2.4.6.
*** Bug 62416 has been marked as a duplicate of this bug. ***
j4rg0n and i took care of this a few days ago.
Closing out bugs that've been resolved for a while now...