Bug 59283 – Porting: glib - charset.alias

• Product: Gentoo Linux
• Status: VERIFIED FIXED

[Description Robin Munn 2004-08-03 09:12:14 UTC]

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"

[Comment 1 Robin Munn 2004-08-03 12:40:12 UTC]

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).

[Comment 2 Hasan Khalil (RETIRED) 2004-08-06 21:09:15 UTC]

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.

[Comment 3 Erik Swanson (RETIRED) 2004-08-06 21:16:23 UTC]

I personally vote for not including a snapshot at all, primarily due to Installer.app's inefficient handling of large numbers of files.

[Comment 4 Robin Munn 2004-08-16 13:17:35 UTC]

Yes, the most recent ebuilds resolve this bug.

[Comment 5 Robin Munn 2004-09-04 18:42:39 UTC]

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.

[Comment 6 Pieter Van den Abeele (RETIRED) 2004-09-24 19:22:57 UTC]

*** Bug 62416 has been marked as a duplicate of this bug. ***

[Comment 7 Hasan Khalil (RETIRED) 2004-09-30 13:20:37 UTC]

j4rg0n and i took care of this a few days ago.

[Comment 8 Hasan Khalil (RETIRED) 2005-02-06 13:33:29 UTC]

Closing out bugs that've been resolved for a while now...