| Summary: | supply ebuild to satisfy virtual/coreutils on macos | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Thomas Stratmann <strattbo> |
| Component: | [OLD] Core system | Assignee: | Gentoo for Mac OS X <ppc-macos> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | base-system, clmason |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | PPC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 59813 | ||
| Bug Blocks: | 58445, 67486, 72705, 73624 | ||
| Attachments: |
Coreutils ebuild for macos
Added pkg_postrm to remove symlinks and addressed solar's concern |
||
|
Description
Thomas Stratmann
2004-07-29 13:30:34 UTC
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 |
