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 |