1 |
On Aug 7, 2005, at 11:48 PM, Finn Thain wrote: |
2 |
|
3 |
> |
4 |
> Firstly can I say thanks for your efforts, I certainly appreciate |
5 |
> it, and |
6 |
> the same for the other Gentoo/OS X devs. It is a tough gig. |
7 |
|
8 |
=) |
9 |
|
10 |
> |
11 |
> On Sun, 7 Aug 2005, Kito wrote: |
12 |
> |
13 |
> |
14 |
>>> |
15 |
>>> Ok, this probably all sounds a bit depressing, or put differently, |
16 |
>>> quite unpromissing. However, all I need for now is some guide |
17 |
>>> into the |
18 |
>>> wilderness I guess. What are the (common) targets of the team? |
19 |
>>> What |
20 |
>>> is it 'we' want to achieve? Who thinks what? |
21 |
>>> |
22 |
>> |
23 |
>> Well, my basic feeling is the current method of trying to accommodate |
24 |
>> Apple supplied userland is futile, its working against the |
25 |
>> advantages of |
26 |
>> the portage tree. |
27 |
>> |
28 |
> |
29 |
> Grobain, he reason this approach was taken (and this can be found |
30 |
> in the |
31 |
> list archives and forum), was that there was no alternative. The |
32 |
> mythical |
33 |
> pathspec was supposed to provide it. And, significantly, pathspec |
34 |
> wasn't |
35 |
> going to be needed to have a Gentoo/Darwin distro, anyway. |
36 |
> |
37 |
> Kito, because of Gentoo/Darwin, this is not futile. And it saves |
38 |
> space on |
39 |
> your own machine. |
40 |
|
41 |
Maybe you misunderstood, what I think is futile is trying to avoid |
42 |
overwriting files, and accommodating things portage has no knowledge |
43 |
of or control over. |
44 |
|
45 |
> OS X has a decent binary package manager, why not |
46 |
> exploit it? Updating a dot release on OS X is easier than emerge -Du |
47 |
> system. |
48 |
|
49 |
Because relying on Apples proprietary stuff is asking for trouble, |
50 |
its liable to change at any given moment without notice. However, |
51 |
emerge'ing from .pkgs is in testing as we speak... |
52 |
|
53 |
> |
54 |
> And if portage acquires the ability to pull deps from several prefixes |
55 |
> (which is apparently part of the plan) it sacrifices nothing to use |
56 |
> OS X |
57 |
> deps. |
58 |
|
59 |
It sacrifices huge amounts of manhours, ebuild consistency, and |
60 |
again, what works with apples current releases will probably not work |
61 |
in future releases...Its pretty hard to second guess at team of >30 |
62 |
engineers on a project without live cvs... |
63 |
|
64 |
> |
65 |
> |
66 |
>> All the apps in portage are tested/tweaked/hacked/patched/whatever to |
67 |
>> work with THE APPS IN PORTAGE, not with 3rd party software |
68 |
>> supplied by |
69 |
>> arbitrary vendors. |
70 |
>> |
71 |
> |
72 |
> There are two problems here: one is the vendor deps, i.e. the present |
73 |
> practice of package.providing deps that are not equivalent to the |
74 |
> ones OS |
75 |
> X provides. This problem goes away as soon as we get ebuilds that can |
76 |
> produce some of apples opensource packages that we use as deps. Apple |
77 |
> being apple, this was always a big ask, but darwinbuild should help. |
78 |
|
79 |
I don't think the problem goes away as much as it changes, although |
80 |
for the better IMHO and this is one of the very things I work on |
81 |
frequently. darwinbuild is a great tool, I've watched it grow and |
82 |
helped hack on it a little bit. Still not quite sure how it will fit |
83 |
into portage in the long run... |
84 |
|
85 |
> |
86 |
> The second problem is that devs now have the job of making sure |
87 |
> that the |
88 |
> portage tree is portable: ebuilds have to work with Portaris, |
89 |
> Gentoo/Darwin, Gentoo/BSD (a lot like Darwin), |
90 |
|
91 |
I wouldn't say a *lot* :p |
92 |
|
93 |
> as well as Gentoo/Linux. |
94 |
> This means a few more guidelines for writing ebuilds, but adds |
95 |
> great value |
96 |
> to the portage tree. |
97 |
|
98 |
Agreed. |
99 |
|
100 |
> |
101 |
> |
102 |
>> In other words, the path of least resistance is allowing portage |
103 |
>> to do |
104 |
>> what it does best, manage software that is has knowledge of, |
105 |
>> instead of |
106 |
>> us constantly lying to it about deps,etc. i.e. when an ebuild has |
107 |
>> DEPEND="app-shells/bash", that means it depends on the bash in |
108 |
>> portage, |
109 |
>> if you have the bash from BeOS/FC4/FBSD/Darwin/NewOS/Whatever its not |
110 |
>> supported, and likely to cause problems somewhere down the line... |
111 |
>> |
112 |
> |
113 |
> Exactly. And this is not new, see the ML archives for the threads on |
114 |
> "optional os x packages" and "zip, and more, in package.provided", |
115 |
> etc. |
116 |
> |
117 |
> |
118 |
>> So, am I saying portage on OS X is a dumb idea? Hell no. Am I |
119 |
>> saying the |
120 |
>> only way I see it working is overwriting Apple files? Hell no. |
121 |
>> |
122 |
>> My personal goals for the project in order of my interest: |
123 |
>> |
124 |
>> A self-hosting Darwin OS build-able and maintainable via portage |
125 |
>> |
126 |
> |
127 |
> Would you use a GNU userland (like GNU/Darwin) or an apple one (like |
128 |
> OpenDarwin and OS X)? |
129 |
|
130 |
Probably somewhere in between. I have the base system building right |
131 |
now, slowly getting some of apples patches into things like python, |
132 |
bash, bsdmake, etc. |
133 |
|
134 |
> |
135 |
> The reason I ask is that the former might mean leveraging the existing |
136 |
> portage tree, whereas the latter might mean creating ebuilds for apple |
137 |
> packages, thus solving the old package.provided problem. |
138 |
|
139 |
I don't think there is a silver bullet here. I already have ebuilds |
140 |
for 50 or so darwin system packages, although not in the portage tree |
141 |
yet until things get stabilized more, but I don't think it will be |
142 |
practical to have one or the other. The main challenge in working |
143 |
with Darwin is keeping up with Apples engineers...no real live cvs is |
144 |
a major pain-in-the-ass, so the source just comes in huge dumps every |
145 |
few months, and with the current G/Darwin dev team of well, me, its a |
146 |
slow process indeed. Any help is appreciated ;) |
147 |
|
148 |
Thanks a bunch for your input, its always nice to hear from people |
149 |
who actually care about this project. |
150 |
|
151 |
--kito |
152 |
|
153 |
> |
154 |
> -f |
155 |
> -- |
156 |
> gentoo-osx@g.o mailing list |
157 |
> |
158 |
> |
159 |
|
160 |
-- |
161 |
gentoo-osx@g.o mailing list |