| 1 |
Firstly can I say thanks for your efforts, I certainly appreciate it, and |
| 2 |
the same for the other Gentoo/OS X devs. It is a tough gig. |
| 3 |
|
| 4 |
On Sun, 7 Aug 2005, Kito wrote: |
| 5 |
|
| 6 |
> > |
| 7 |
> >Ok, this probably all sounds a bit depressing, or put differently, |
| 8 |
> >quite unpromissing. However, all I need for now is some guide into the |
| 9 |
> >wilderness I guess. What are the (common) targets of the team? What |
| 10 |
> >is it 'we' want to achieve? Who thinks what? |
| 11 |
> |
| 12 |
> Well, my basic feeling is the current method of trying to accommodate |
| 13 |
> Apple supplied userland is futile, its working against the advantages of |
| 14 |
> the portage tree. |
| 15 |
|
| 16 |
Grobain, he reason this approach was taken (and this can be found in the |
| 17 |
list archives and forum), was that there was no alternative. The mythical |
| 18 |
pathspec was supposed to provide it. And, significantly, pathspec wasn't |
| 19 |
going to be needed to have a Gentoo/Darwin distro, anyway. |
| 20 |
|
| 21 |
Kito, because of Gentoo/Darwin, this is not futile. And it saves space on |
| 22 |
your own machine. OS X has a decent binary package manager, why not |
| 23 |
exploit it? Updating a dot release on OS X is easier than emerge -Du |
| 24 |
system. |
| 25 |
|
| 26 |
And if portage acquires the ability to pull deps from several prefixes |
| 27 |
(which is apparently part of the plan) it sacrifices nothing to use OS X |
| 28 |
deps. |
| 29 |
|
| 30 |
> All the apps in portage are tested/tweaked/hacked/patched/whatever to |
| 31 |
> work with THE APPS IN PORTAGE, not with 3rd party software supplied by |
| 32 |
> arbitrary vendors. |
| 33 |
|
| 34 |
There are two problems here: one is the vendor deps, i.e. the present |
| 35 |
practice of package.providing deps that are not equivalent to the ones OS |
| 36 |
X provides. This problem goes away as soon as we get ebuilds that can |
| 37 |
produce some of apples opensource packages that we use as deps. Apple |
| 38 |
being apple, this was always a big ask, but darwinbuild should help. |
| 39 |
|
| 40 |
The second problem is that devs now have the job of making sure that the |
| 41 |
portage tree is portable: ebuilds have to work with Portaris, |
| 42 |
Gentoo/Darwin, Gentoo/BSD (a lot like Darwin), as well as Gentoo/Linux. |
| 43 |
This means a few more guidelines for writing ebuilds, but adds great value |
| 44 |
to the portage tree. |
| 45 |
|
| 46 |
> In other words, the path of least resistance is allowing portage to do |
| 47 |
> what it does best, manage software that is has knowledge of, instead of |
| 48 |
> us constantly lying to it about deps,etc. i.e. when an ebuild has |
| 49 |
> DEPEND="app-shells/bash", that means it depends on the bash in portage, |
| 50 |
> if you have the bash from BeOS/FC4/FBSD/Darwin/NewOS/Whatever its not |
| 51 |
> supported, and likely to cause problems somewhere down the line... |
| 52 |
|
| 53 |
Exactly. And this is not new, see the ML archives for the threads on |
| 54 |
"optional os x packages" and "zip, and more, in package.provided", etc. |
| 55 |
|
| 56 |
> So, am I saying portage on OS X is a dumb idea? Hell no. Am I saying the |
| 57 |
> only way I see it working is overwriting Apple files? Hell no. |
| 58 |
> |
| 59 |
> My personal goals for the project in order of my interest: |
| 60 |
> |
| 61 |
> A self-hosting Darwin OS build-able and maintainable via portage |
| 62 |
|
| 63 |
Would you use a GNU userland (like GNU/Darwin) or an apple one (like |
| 64 |
OpenDarwin and OS X)? |
| 65 |
|
| 66 |
The reason I ask is that the former might mean leveraging the existing |
| 67 |
portage tree, whereas the latter might mean creating ebuilds for apple |
| 68 |
packages, thus solving the old package.provided problem. |
| 69 |
|
| 70 |
-f |
| 71 |
-- |
| 72 |
gentoo-osx@g.o mailing list |
Archives