Firstly can I say thanks for your efforts, I certainly appreciate it, and the same for the other Gentoo/OS X devs. It is a tough gig.
On Sun, 7 Aug 2005, Kito wrote: > > > >Ok, this probably all sounds a bit depressing, or put differently, > >quite unpromissing. However, all I need for now is some guide into the > >wilderness I guess. What are the (common) targets of the team? What > >is it 'we' want to achieve? Who thinks what? > > Well, my basic feeling is the current method of trying to accommodate > Apple supplied userland is futile, its working against the advantages of > the portage tree. Grobain, he reason this approach was taken (and this can be found in the list archives and forum), was that there was no alternative. The mythical pathspec was supposed to provide it. And, significantly, pathspec wasn't going to be needed to have a Gentoo/Darwin distro, anyway. Kito, because of Gentoo/Darwin, this is not futile. And it saves space on your own machine. OS X has a decent binary package manager, why not exploit it? Updating a dot release on OS X is easier than emerge -Du system. And if portage acquires the ability to pull deps from several prefixes (which is apparently part of the plan) it sacrifices nothing to use OS X deps. > All the apps in portage are tested/tweaked/hacked/patched/whatever to > work with THE APPS IN PORTAGE, not with 3rd party software supplied by > arbitrary vendors. There are two problems here: one is the vendor deps, i.e. the present practice of package.providing deps that are not equivalent to the ones OS X provides. This problem goes away as soon as we get ebuilds that can produce some of apples opensource packages that we use as deps. Apple being apple, this was always a big ask, but darwinbuild should help. The second problem is that devs now have the job of making sure that the portage tree is portable: ebuilds have to work with Portaris, Gentoo/Darwin, Gentoo/BSD (a lot like Darwin), as well as Gentoo/Linux. This means a few more guidelines for writing ebuilds, but adds great value to the portage tree. > In other words, the path of least resistance is allowing portage to do > what it does best, manage software that is has knowledge of, instead of > us constantly lying to it about deps,etc. i.e. when an ebuild has > DEPEND="app-shells/bash", that means it depends on the bash in portage, > if you have the bash from BeOS/FC4/FBSD/Darwin/NewOS/Whatever its not > supported, and likely to cause problems somewhere down the line... Exactly. And this is not new, see the ML archives for the threads on "optional os x packages" and "zip, and more, in package.provided", etc. > So, am I saying portage on OS X is a dumb idea? Hell no. Am I saying the > only way I see it working is overwriting Apple files? Hell no. > > My personal goals for the project in order of my interest: > > A self-hosting Darwin OS build-able and maintainable via portage Would you use a GNU userland (like GNU/Darwin) or an apple one (like OpenDarwin and OS X)? The reason I ask is that the former might mean leveraging the existing portage tree, whereas the latter might mean creating ebuilds for apple packages, thus solving the old package.provided problem. -f -- [email protected] mailing list
