Bug 509596

Summary:	sys-apps/coreutils removes /bin/dircolors when /usr/bin/dircolors exists, even when /usr is a symlink to /
Product:	Gentoo Linux	Reporter:	Duncan <1i5t5.duncan>
Component:	[OLD] Core system	Assignee:	Gentoo's Team for Core System packages <base-system>
Status:	RESOLVED FIXED
Severity:	normal	CC:	stefan, temporale
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
See Also:	https://bugs.gentoo.org/show_bug.cgi?id=224823
Whiteboard:
Package list:		Runtime testing required:	---

Description Duncan 2014-05-05 06:04:20 UTC

+++ This bug was initially created as a clone of Bug #224823 +++

While this bug started as that clone, it's really the result of the fix for the the above bug.

The bug trigger is that I'm running a unified /usr /, with:

/usr -> ./

Portage actually handles that well in general, and this is the first problem I've come across as a result, due not to portage but to bad assumptions in a specific ebuild.  Now I have no dircolors!

An investigation pointed me at the line in the ebuild that deletes it, and the corresponding bug cloned above. =:^(

Suggested fix: Use readlink or realpath to resolve both /usr/bin/dircolors and /bin/dircolors and only continue with the rm if they are not the same file.

Using realpath, the test clause to add before doing the rm could look like this:

[[ $(realpath /usr/bin/dircolors) != $(realpath /bin/dircolors) ]] &&

Comment 1 SpanKY gentoo-dev

2014-05-05 18:10:46 UTC

we've probably outlived that migration codepath now, so we can just delete it

Comment 2 SpanKY gentoo-dev

2014-05-08 19:41:49 UTC

should be all set now in the tree; thanks for the report!

Commit message: Drop old migration logic as we have moved way beyond it and it causes issues with /usr merge
http://sources.gentoo.org/sys-apps/coreutils/coreutils-8.22-r1.ebuild?r1=1.1&r2=1.2