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 attachment 64994 [details, diff] 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
