1 |
On Oct 31, 2005, at 1:34 PM, Grobian wrote: |
2 |
|
3 |
> Kito wrote: |
4 |
>>> My personal targets for this project are as follows: |
5 |
>>> 1. Make Gentoo for OSX an acceptable sub-project of the Gentoo |
6 |
>>> family. |
7 |
>>> 2. Get a prefixed install to make Gentoo for OSX comparative to |
8 |
>>> Fink and |
9 |
>>> Darwin Ports, and quality wise go beyond. |
10 |
>> Why (2) is not first on everyones priority list, I really don't |
11 |
>> understand. If we can do (2) in a reasonably sane fashion, (1) |
12 |
>> will 'just happen'. |
13 |
> |
14 |
> Well. Not that I don't agree with you, but I don't have as much of |
15 |
> a good indication how far away we are from the holy grail. Hence, |
16 |
> in the meanwhile while *I* have to wait for the long awaited gift |
17 |
> from above, I try to fix those things that are possible without the |
18 |
> prefix. However, if I would have to chose between a prefixed |
19 |
> portage next week, or getting a lot of ebuilds sane within a week, |
20 |
> I wouldn't hestitate to go for the first one. Hope this calms you |
21 |
> down a bit ;) I just reasoned from my own perspective as in what |
22 |
> *I can* do. I have limitations also. |
23 |
|
24 |
This wasn't aimed directly at just you... I try to avoid using |
25 |
political jargon like saying 'everyone' when I mean one person in |
26 |
particular. In fact, you are the only person who *has* at least |
27 |
responded to my proposals on this in the past. I really meant |
28 |
everyone(myself included). I didn't make prefixes a priority for |
29 |
myself either until a few months back when some of the dev seeds I |
30 |
was getting from apple made it blatantly obvious that relying on the |
31 |
moving target known as OS X is a dead-end. I really just feel |
32 |
spending my time getting prefixes closer to being a reality, is a |
33 |
much bigger benefit to the project than getting app-obscure/ |
34 |
widget-5.0 keyworded ppc-macos and closing a bug. |
35 |
|
36 |
> |
37 |
> Would you like to lead this sub-project, define roles, tasks and |
38 |
> roll out a todo list or some minimalistic readme, so people can get |
39 |
> involved and perhaps start wondering around in the code? |
40 |
|
41 |
I'm not sure it warrants a sub-project, but if the consensus is that |
42 |
it does, I suppose I could lead it if noone else wants to. Hopefully |
43 |
I'll have some stuff to post in the coming week - an xml project |
44 |
page, very very rough 'getting started' doc, a prefixed os x |
45 |
stage1/3, pkg installer, and overlay snapshot. Considering the |
46 |
fragile nature of it all, and that whatever we/I come up with will |
47 |
function merely as a working prototype, I'm not sure how 'official' |
48 |
it should really get... |
49 |
|
50 |
> |
51 |
>> Again, I think that once a product exists that is actually useful, |
52 |
>> both devs and users a like will start showing up...bit of a |
53 |
>> chicken/egg situation I know, but this is opensource, without a |
54 |
>> strong userbase, we won't ever have a strong dev team. |
55 |
> |
56 |
> It is of a not so big concern of me now. It is on the road ahead. |
57 |
> In the end it's much easier to craft the very kernel of our project |
58 |
> with a small team, IMHO. |
59 |
|
60 |
Yes, we have talked about this before, and I think we are in complete |
61 |
agreement. |
62 |
|
63 |
> |
64 |
>>> To conclude a short note on various flavours of the project, such as |
65 |
>>> progressive and darwin. I am not interested in those myself. My |
66 |
>>> main |
67 |
>>> focus is on the 'consumer product', which should be the mainline |
68 |
>>> product, or the collision-protect profiles as they are called |
69 |
>>> now. The |
70 |
>>> fact that I am not interested (yet) into these profiles, does not |
71 |
>>> mean I |
72 |
>>> will never support them. I would just like to focus on getting the |
73 |
>>> mainline (normal users) product going, then if people have a |
74 |
>>> personal |
75 |
>>> target to create a progressive profile for instance, I will not stop |
76 |
>>> such development -- not even wondering on how I would be able to |
77 |
>>> stop it |
78 |
>>> anyway. I consider one of my personal wishes for a 64-bit |
79 |
>>> install to |
80 |
>>> be a profile that should walk the same path like a progressive |
81 |
>>> profile: |
82 |
>>> it should wait till there is a working mainline product. |
83 |
>> To follow that logic, why are we continuing to mark things ~ppc- |
84 |
>> macos when we don't even have a working a mainline product? I look |
85 |
>> at the progressive profile about the same as you look at mass |
86 |
>> keywording for all of dirks bug reports..."Its not extremely |
87 |
>> useful right now, but the work will have to be done at some point, |
88 |
>> so why not now?" |
89 |
> |
90 |
> Because I still don't understand the idea of progressive, and I do |
91 |
> understand myself a bit sometimes. So for me, progressive is a |
92 |
> skim that exists in bugzilla, but every bug assigned to progressive |
93 |
> is basically dead. ~ppc-macos is simply the testing side of the |
94 |
> mainline product we have. |
95 |
|
96 |
But again, without the progressive profile, this past weekend when it |
97 |
came time to get all the system packages merging, I would have been |
98 |
starting from square1, as opposed to being able to quickly take |
99 |
advantage of ~12 months of hard work. Had we/I not had this means of |
100 |
keywording packages that collide with apple files, I'd still be |
101 |
fighting with spanky on getting the bash ebuild darwin-safe, instead |
102 |
of tackling the global problems of getting prefixes working. |
103 |
|
104 |
> |
105 |
>> Building a prefixed stage1 went extremely quickly because most of |
106 |
>> the base-system packages had already been ported to OS X via my |
107 |
>> work with the base-system people(ok, mainly just spanky ;) on the |
108 |
>> progressive profile(perl,bash,coreutils,gcc- |
109 |
>> apple,flex,bison,python,auto*,texinfo,zlib,bzip2,rsync, etc. |
110 |
>> etc.). This attitude of 'we only support the consumer product' is |
111 |
>> a good outward goal, but is also what IMHO contributed to the half- |
112 |
>> assed nature of the current collision-protect profiles...i.e. "We |
113 |
>> have a very short sighted implementation, that is a maintenance |
114 |
>> nightmare, requires very heavy modifications to the tree, and has |
115 |
>> virtually 0 appeal to both devs and users, but lets keep working |
116 |
>> hard and try to get gaim and x-chat keyworded ppc-macos because |
117 |
>> its what users want." |
118 |
> |
119 |
> Yeah, ok. But do you have a better solution? |
120 |
|
121 |
I believe I do yes... and I'm working on it :p |
122 |
|
123 |
> Its not *my* fault that we're in the mess we're in. |
124 |
|
125 |
I was by no means implying that it was your fault... |
126 |
|
127 |
> I just try to use pure management logic at the moment. Might be |
128 |
> short sighted... but on the other hand, I'm not going to ask |
129 |
> someone to wait a few months or maybe a year with going |
130 |
> systematically through portage and check everything if it compiles |
131 |
> or not. I'm just very happy that such person wants to go through |
132 |
> that horror. |
133 |
> |
134 |
>> What I'm saying is, darwin and progressive provide a testbed for |
135 |
>> the bottom-up approach that we should have been taking from the |
136 |
>> beginning. |
137 |
> |
138 |
> Don't blame me for what's not my fault. |
139 |
|
140 |
I'm really not laying blame on any one person... |
141 |
|
142 |
> It has *absolutely* no use to keep on telling what is wrong now at |
143 |
> the moment. The only way out of there is what ciarmn would like to |
144 |
> see the best: remove the full ppc-macos keyword from the tree. |
145 |
> Then what ciarmn wouldn't like so much to see is that you can start |
146 |
> all over from scratch in an overlay. |
147 |
|
148 |
I'm not sure I followed that thought. |
149 |
|
150 |
> |
151 |
> Stressing the importance of progressive or darwin is ok. I won't |
152 |
> deny you are right, but as a project in itself it is not of |
153 |
> relevance. It is implicit for me that you need the clean compiles |
154 |
> in the prefix, but when you have that, I simply don't see what a |
155 |
> progressive profile would bring in advantages. |
156 |
> The mainline profile of prefixed installs is more or less what "- |
157 |
> collision-protect" is now. From a user perspective. |
158 |
> |
159 |
> Maybe I think way to simple for you, or with a too commercial |
160 |
> vision. I just think it's better to move, instead of sink away |
161 |
> deeper in the sand. |
162 |
|
163 |
Err...huh? |
164 |
|
165 |
--Kito |
166 |
|
167 |
-- |
168 |
gentoo-osx@g.o mailing list |