Bugzilla Bug 101218

As I'm trying to get some sort of GNU-compatibility for end users on  
Gentoo/FreeBSD, I need to have coreutils working on Gentoo/FreeBSD.  
Sources compiles fine on Gentoo/FreeBSD without problems or collisions (a part  
charset.alias, sure), so I changed the ebuild to make it support non-GNU  
userlands as well as the default GNU userlands. 
 
When installed in a non-GNU userland, it installs every binary with g-prefix  
and in /usr/bin instead of /bin, so it doesn't need to move them around; it  
also avoid to touch /usr/bin/hostname. 
 
The change is a no-op for GNU systems. 
 
Thanks in advance, 
Diego

Created an attachment (id=64994) [edit]
Ebuild patch

Actually ${D}/usr/lib should be ${D}/usr/$(get_libdir) when removing the 
charset.alias. 
 

i dont like this change ... i dont see much benefit installing coreutils like
this

Read on my blog 
( http://planet.gentoo.org/developers/flameeyes/2005/08/03/p268 ), it's to 
allow users to have gnu-style userland commands if they are too used to them. 
 

Looks fine beside those lines:

+
+	rm -f ${D}/usr/lib/charset.alias

Segregate the with as you planned on irc

+	# charset.alias provided by libiconv on non glibc systems
+	# and not built on glibc
+	use elibc_glibc || rm -f ${D}/usr/lib/charset.alias

or patch the build system to avoid building it on libiconv presence.

/usr/lib/charset.alias should never be produced by anything on a GNU system
afaik

the '-f' passed to 'rm' will keep rm from erroring, so no point in adding the
`use`

sync up and try out what ive committed to 5.2.1-r6

Thanks, works fine. 
I've only committed a change to ChangeLog to fix the spelling of my name :P