1 |
Kito wrote: |
2 |
>> My personal targets for this project are as follows: |
3 |
>> 1. Make Gentoo for OSX an acceptable sub-project of the Gentoo family. |
4 |
>> 2. Get a prefixed install to make Gentoo for OSX comparative to Fink and |
5 |
>> Darwin Ports, and quality wise go beyond. |
6 |
> |
7 |
> Why (2) is not first on everyones priority list, I really don't |
8 |
> understand. If we can do (2) in a reasonably sane fashion, (1) will |
9 |
> 'just happen'. |
10 |
|
11 |
Well. Not that I don't agree with you, but I don't have as much of a |
12 |
good indication how far away we are from the holy grail. Hence, in the |
13 |
meanwhile while *I* have to wait for the long awaited gift from above, I |
14 |
try to fix those things that are possible without the prefix. However, |
15 |
if I would have to chose between a prefixed portage next week, or |
16 |
getting a lot of ebuilds sane within a week, I wouldn't hestitate to go |
17 |
for the first one. Hope this calms you down a bit ;) I just reasoned |
18 |
from my own perspective as in what *I can* do. I have limitations also. |
19 |
|
20 |
>> 2. A prefixed install for me means having a way to install into |
21 |
>> /Library/Gentoo, /Gentoo, /Users/Library/Gentoo or wherever. I don't |
22 |
>> really care about the location, and a system wide install would be |
23 |
>> fine with me too. I envision that a touch discussion on variable |
24 |
>> prefixes, or homedir prefixes and whatever will follow if not yet |
25 |
>> have been on the portage channels. What I would like to see is that |
26 |
>> we can play with it, maybe not in its ideal state, but those |
27 |
>> improvements can be made while we're playing. |
28 |
> |
29 |
> My impression is everyone in the OS X team feels this is something thats |
30 |
> going to get immaculately implemented by the portage gods, leaving us to |
31 |
> reap the benefits.... not likely... If we don't do the work, no one |
32 |
> will. I've been trying for months to no avail to get others involved so |
33 |
> we can start 'playing with it'. Can lead a horse to water but can't make |
34 |
> him drink I suppose... |
35 |
|
36 |
Hmmm... Yeah... Well I don't know what to say. Of course you're right |
37 |
in the first part. The reason I let it slide was that I couldn't cope |
38 |
with you guys to stick up-to-date. I really regret to hear your |
39 |
complaint only now. Not that I think I can change it much, again, I am |
40 |
a limited edition (in multiple ways ;) ). |
41 |
|
42 |
>> - Although I have seen signals that we're close to something like |
43 |
>> this (kudos to Kito and Brian) |
44 |
> |
45 |
> I have a self-hosting toolchain working in a prefix right now. Tons of |
46 |
> bugs, tons of things not implemented yet, etc. etc. but its a solid |
47 |
> start. Keep in mind, this should only be considered a proof-of-concept, |
48 |
> mainly to help determine the requirements of the ebuilds when working in |
49 |
> a prefixed environment. |
50 |
> |
51 |
> My rough plan is to squash a few of the major bugs left |
52 |
> (collision-protect and binpkgs primarily), with brians help roll a new |
53 |
> patch against current stable portage(using rc4 currently), check my |
54 |
> overlay into the alt svn module, create a "developers preview" install |
55 |
> pkg, and then continue adding ebuilds to the EAPI=1 overlay, adding |
56 |
> features/bug squashing as we go. Once the overlay is in a fairly |
57 |
> workable state, we can start/continue the beloved GLEP/Flaming process |
58 |
> we all know and love. |
59 |
> |
60 |
> Brian has better insight than I on the long-term roadmap, so hopefully |
61 |
> he'll chime in here, but my guess is the very very earliest we could see |
62 |
> prefixed support in mainline would be around the time of saviours(3.0) |
63 |
> official release... but in the meantime there is by no means any |
64 |
> shortage of work to be done... |
65 |
> |
66 |
> All that being said, the more people working towards this same goal, the |
67 |
> higher the probability of its success and eventual adoption by Gentoo |
68 |
> proper. |
69 |
|
70 |
Would you like to lead this sub-project, define roles, tasks and roll |
71 |
out a todo list or some minimalistic readme, so people can get involved |
72 |
and perhaps start wondering around in the code? |
73 |
I just say this because I think you are the one with the knowledge here. |
74 |
Feel free to post regular updates of the ongoing work, bottle-necks, |
75 |
issues and where work is needed to the list. |
76 |
|
77 |
> Again, I think that once a product exists that is actually useful, both |
78 |
> devs and users a like will start showing up...bit of a chicken/egg |
79 |
> situation I know, but this is opensource, without a strong userbase, we |
80 |
> won't ever have a strong dev team. |
81 |
|
82 |
It is of a not so big concern of me now. It is on the road ahead. In |
83 |
the end it's much easier to craft the very kernel of our project with a |
84 |
small team, IMHO. |
85 |
|
86 |
>> To conclude a short note on various flavours of the project, such as |
87 |
>> progressive and darwin. I am not interested in those myself. My main |
88 |
>> focus is on the 'consumer product', which should be the mainline |
89 |
>> product, or the collision-protect profiles as they are called now. The |
90 |
>> fact that I am not interested (yet) into these profiles, does not mean I |
91 |
>> will never support them. I would just like to focus on getting the |
92 |
>> mainline (normal users) product going, then if people have a personal |
93 |
>> target to create a progressive profile for instance, I will not stop |
94 |
>> such development -- not even wondering on how I would be able to stop it |
95 |
>> anyway. I consider one of my personal wishes for a 64-bit install to |
96 |
>> be a profile that should walk the same path like a progressive profile: |
97 |
>> it should wait till there is a working mainline product. |
98 |
> |
99 |
> To follow that logic, why are we continuing to mark things ~ppc-macos |
100 |
> when we don't even have a working a mainline product? I look at the |
101 |
> progressive profile about the same as you look at mass keywording for |
102 |
> all of dirks bug reports..."Its not extremely useful right now, but the |
103 |
> work will have to be done at some point, so why not now?" |
104 |
|
105 |
Because I still don't understand the idea of progressive, and I do |
106 |
understand myself a bit sometimes. So for me, progressive is a skim |
107 |
that exists in bugzilla, but every bug assigned to progressive is |
108 |
basically dead. ~ppc-macos is simply the testing side of the mainline |
109 |
product we have. |
110 |
|
111 |
> Building a prefixed stage1 went extremely quickly because most of the |
112 |
> base-system packages had already been ported to OS X via my work with |
113 |
> the base-system people(ok, mainly just spanky ;) on the progressive |
114 |
> profile(perl,bash,coreutils,gcc-apple,flex,bison,python,auto*,texinfo,zlib,bzip2,rsync, |
115 |
> etc. etc.). This attitude of 'we only support the consumer product' is |
116 |
> a good outward goal, but is also what IMHO contributed to the half-assed |
117 |
> nature of the current collision-protect profiles...i.e. "We have a very |
118 |
> short sighted implementation, that is a maintenance nightmare, requires |
119 |
> very heavy modifications to the tree, and has virtually 0 appeal to both |
120 |
> devs and users, but lets keep working hard and try to get gaim and |
121 |
> x-chat keyworded ppc-macos because its what users want." |
122 |
|
123 |
Yeah, ok. But do you have a better solution? Its not *my* fault that |
124 |
we're in the mess we're in. I just try to use pure management logic at |
125 |
the moment. Might be short sighted... but on the other hand, I'm not |
126 |
going to ask someone to wait a few months or maybe a year with going |
127 |
systematically through portage and check everything if it compiles or |
128 |
not. I'm just very happy that such person wants to go through that horror. |
129 |
|
130 |
> What I'm saying is, darwin and progressive provide a testbed for the |
131 |
> bottom-up approach that we should have been taking from the beginning. |
132 |
|
133 |
Don't blame me for what's not my fault. It has *absolutely* no use to |
134 |
keep on telling what is wrong now at the moment. The only way out of |
135 |
there is what ciarmn would like to see the best: remove the full |
136 |
ppc-macos keyword from the tree. Then what ciarmn wouldn't like so much |
137 |
to see is that you can start all over from scratch in an overlay. |
138 |
|
139 |
Stressing the importance of progressive or darwin is ok. I won't deny |
140 |
you are right, but as a project in itself it is not of relevance. It is |
141 |
implicit for me that you need the clean compiles in the prefix, but when |
142 |
you have that, I simply don't see what a progressive profile would bring |
143 |
in advantages. The mainline profile of prefixed installs is more or |
144 |
less what "-collision-protect" is now. From a user perspective. |
145 |
|
146 |
Maybe I think way to simple for you, or with a too commercial vision. I |
147 |
just think it's better to move, instead of sink away deeper in the sand. |
148 |
|
149 |
|
150 |
-- |
151 |
Fabian Groffen |
152 |
Gentoo for Mac OS X Project -- Interim Lead |
153 |
-- |
154 |
gentoo-osx@g.o mailing list |