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?
>>> 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
> pathspec was supposed to provide it. And, significantly, pathspec
> 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
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
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
>> 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",
>> 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.
> firstname.lastname@example.org mailing list
email@example.com mailing list