Mac OS X dislikes symlinks to a relative path. My installer creates such a symlink (etc/make.profile). Remove the /etc/make.profile symlink and recreate it using full paths. Instead of ../usr/portage/profiles/... use /usr/portage/... as target. I'll update the installer asap. The current installer uses ARCH="macos" but keyword="ppc" . Apparently you can only use the keyword mentioned in your ARCH. If you want to experiment with portage itself and want to keep ebuilds for later, set ARCH to ppc and keywords to ppc. You'll be able to do emerge -vp nano without portage complaining about apps not being keyworded. We are going to use ARCH="macos" and ACCEPT_KEYWORDS="macos" I've added virtual/libc for a new dummy ebuild sys-libs/libsystem. (similar to darwinports). I've then started masking and patching the dependency tree for several packages: wget, nano, tetex, passook, makepassword, ... Whereever needed apps are masked stable on macos (sometimes after patching them). Where needed, I've added Darwin variants of packages. I've discovered that at least the following packages are provided by apple and can be injected if you want to emerge the packages mentioned above right now. bash python autoconf automake libtool (note that this is installed as glibtool <- ebuilds need to use glibtool, and glibtoolize, otherwise you'll end up using the libtool app which does something completely different on ppc). perl, grep, miscfiles, zlib ed sed texinfo These packages should be injected automatically at startup. My first thought was to create 'dummy's for all them and put them in the system profile. Emerge system would then emerge all the dummies. The profile would pin down the version of a dummy. Right now I'm thinking to reuse a custom bootstrap.sh script. This script would basically inject all packages provided by apple. emerge system would include some things we like to ship by default (nano, portage, ... ) = a small superset the apps provided by Darwin. I've discovered a but in my portage snapshot: when you abort the emerge, or the emerge fails inside src_install, it will leave some lock files open. Remerge the lockfiles to proceed with emerging. I have a patch ready. Will make next installer. By default portage installs to /. For some reason I have come to like that. You don't need all the PATH tweaks, gentoo can uninstall software you installed, and it knows how to upgrade it. I would like to provide an option to install in /opt/local or something, but that isn't high on my todo right now. I'd say the stuff is progressing quite nicely. I'd like to have something useable by next meeting (useable = install, automatic set up, a few apps emergeable (preferably tetex, maybe mysql)) That way we'll be able to divide into groups: people who'd like to attack portage and test features such as the prefixed installs (ROOT=/opt/local/ emerge ... ) other people who start porting a bunch of apps and their deps. (Python seems a difficult one, kde, gnome, fluxbox ... ), a bunch of people that document the thing, create a website, take on recruiting, ... Thoughts welcome of course
With the new installer: install using the installer. open terminal, run /usr/portage/scripts/bootstrap-macos.sh then run emerge system I can have the installer do all this for you. Ideas?
IMHO the installer should run the bootstrap script to get the existing system injected. After that, the user should be responsable for an 'emerge sync' followed by 'emerge system'. Good Idea/Bad Idea?
The installer now does this automatically. Support integrated into portage: The system profiles package.provided file indicates which packages are assumed installed on a gentoo system
Closing out bugs that've been resolved for a while now...
