darwin provides part, but not all of what sys-apps/coreutils gives for linux (no tac, for example). a decision has to be made somewhere between leaving darwin's part and filling up with gnu programs, or having all tools from gnu. Reproducible: Didn't try Steps to Reproduce: 1. 2. 3.
From what I can tell, the only thing that severely breaks os x is uname from coreutils. uname -p will give 'unknown'. It appears the coreutils in cvs at gnu.org has a small patch that might fix that...
Current Gentoo for Mac OS X porting policy is that overwriting files that were not installed by portage is unacceptable. We are going to have to make g<util>'s out of each of the coreutils, unless anyone has a better suggestion.
*** Bug 58818 has been marked as a duplicate of this bug. ***
Created attachment 38825 [details] Coreutils ebuild for macos As discussed in the gentoo-macos meeting, this ebuild fills the coreutils virtual. It adds the missing utilities and creates symlinks for the already present utilities. Please let me know if there are any problems with this ebuild. Thanks!
Little QA note about attachment #38825 [details] LDFLAGS should never be completely overridden by any ebuild. ebuilds should always use append-ldflags -static or LDFLAGS="${LDFLAGS} -static" append-ldflags comes from flag-o-matic.eclass
Created attachment 38859 [details] Added pkg_postrm to remove symlinks and addressed solar's concern
There already exists a uname on OSX. Is it significantly different that we would want a g<util> out of it? Is there anything else we {want,need} a g<util> out of? Otherwise, can we push Joe's awesome ebuild through?
Some things I'd change... * Move the global vars to pkg_setup. * for foo in `ls` is *really* icky, don't do that * Fix KEYWORDS
re: uname gnu uname is alot different than the apple provided and is broken in its current release, however it is fixed in CVS, so we should grab that patch from upstream and install it as guname i suppose.
Okay, I've added the cvs patch for uname and installed it as guname, put the global vars in pkg_setup and fixed the keyword. (It's been sitting here since before the keyword change!) Ciaran, what do you suggest instead of using ls? I can just make more variables I suppose. Once I've addressed that, I'll put up another ebuild. To actually get this is portage, we also need to add a corutils virtual, does anyone want to take responsibility for this?
I've added a slightly updated version of this to portage, but have not yet tackled actually creating the virtual/coreutils. For now this is adequate, but we will want to do this in the future. I have no idea if any of these coreutils are provided with 10.4, so please let me know if there are collisions. Thanks!
I've added coreutils-darwin-5.3.0 to portage today, this is the latest release and is still considered alpha by upstream, but it may work better for us. Please try it out and see what works for you. Thanks!
What's the status of this bug? It appears all problems that were related to this bug have been resolved, and I was able to emerge coreutils-darwin without problems. Can this bug be closed?
I think what still needs to be done here is the creation of the virtual so that we satisfy the DEPEND for packages needing coreutils. I'm not sure if this has been taken care of yet.
it appears not to be in the virtuals for darwin or darwin/macos yet.
old
