Gentoo Archives: gentoo-osx

From: Kito <kito@g.o>
To: gentoo-osx@l.g.o
Subject: Re: [gentoo-osx] Some Introduction
Date: Mon, 08 Aug 2005 05:39:13
In Reply to: Re: [gentoo-osx] Some Introduction by Finn Thain
On Aug 7, 2005, at 11:48 PM, Finn Thain wrote:

> > 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.
Maybe you misunderstood, what I think is futile is trying to avoid overwriting files, and accommodating things portage has no knowledge of or control over.
> 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.
Because relying on Apples proprietary stuff is asking for trouble, its liable to change at any given moment without notice. However, emerge'ing from .pkgs is in testing as we speak...
> > 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.
It sacrifices huge amounts of manhours, ebuild consistency, and again, what works with apples current releases will probably not work in future releases...Its pretty hard to second guess at team of >30 engineers on a project without live cvs...
> > >> 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.
I don't think the problem goes away as much as it changes, although for the better IMHO and this is one of the very things I work on frequently. darwinbuild is a great tool, I've watched it grow and helped hack on it a little bit. Still not quite sure how it will fit into portage in the long run...
> > 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),
I wouldn't say a *lot* :p
> 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)?
Probably somewhere in between. I have the base system building right now, slowly getting some of apples patches into things like python, bash, bsdmake, etc.
> > 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.
I don't think there is a silver bullet here. I already have ebuilds for 50 or so darwin system packages, although not in the portage tree yet until things get stabilized more, but I don't think it will be practical to have one or the other. The main challenge in working with Darwin is keeping up with Apples real live cvs is a major pain-in-the-ass, so the source just comes in huge dumps every few months, and with the current G/Darwin dev team of well, me, its a slow process indeed. Any help is appreciated ;) Thanks a bunch for your input, its always nice to hear from people who actually care about this project. --kito
> > -f > -- > gentoo-osx@g.o mailing list > >
-- gentoo-osx@g.o mailing list


Subject Author
Re: [gentoo-osx] Some Introduction Cap'n Hector <me@×××××××××.com>
Re: [gentoo-osx] Some Introduction Finn Thain <fthain@××××××××××××××××.au>
Re: [gentoo-osx] Some Introduction Stroller <macmonster@×××××××××.com>