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.

Agreed.

>
>
>> 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 engineers...no 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