1 |
On Oct 31, 2005, at 6:16 PM, m h wrote: |
2 |
|
3 |
> Kito- |
4 |
> |
5 |
> Are you leveraging the work done by Haubi documented here: |
6 |
> http://gentoo-wiki.com/HOWTO_Use_prefixed_portage_%28in_development%29 |
7 |
> ??? |
8 |
|
9 |
Yeah, Brian backported his 2.1 patch to 2.0, and we've had some |
10 |
additional changes like strict PATH handling(portage requires the |
11 |
toolchain to live in ${PREFIX}), no use of ${AFFIX} (save that for |
12 |
later, when portage can manage interdomain deps), ${D} and ${ROOT} |
13 |
autoexpanded to ${BUILDDIR}/image/${PREFIX} in the ebuild env to |
14 |
limit the required changes to ebuilds, addition of the ${DEST} |
15 |
variable for make install DESTDIR targets, also some extra ebuild.sh |
16 |
functions for setting custom bindir,infodir,sysconf,libdir |
17 |
configuration options in non-econf configured ebuilds, and various |
18 |
do* utils fixes. |
19 |
|
20 |
As it sits right now, the ebuild changes required are very very |
21 |
minor, which is of utmost importance if this is ever going to fly. |
22 |
|
23 |
> |
24 |
> Just wondering because I've been able to use this to get portage |
25 |
> installed on a FC4 system (I know it's not OSX). But another user has |
26 |
> been able to use this to install over 200 packages on an AIX system. |
27 |
|
28 |
Excellent. As I mentioned earlier, later this week I hope to get some |
29 |
barebones docs and the overlay checked into the alt svn repo. The |
30 |
current method will require arch specific tarballs, so hopefully we |
31 |
can coordinate effort on this as I've only been targeting Darwin/ |
32 |
OSX... the more portable it is, the better. |
33 |
|
34 |
--Kito |
35 |
|
36 |
> |
37 |
> matt |
38 |
> |
39 |
> On 10/31/05, Kito <kito@g.o> wrote: |
40 |
>> |
41 |
>> On Oct 30, 2005, at 4:49 AM, Grobian wrote: |
42 |
>> |
43 |
>>> Since it "is silly if you want things to work before several years |
44 |
>>> off" |
45 |
>>> [1], perhaps it's not that useful to discuss this issue. |
46 |
>>> However, we |
47 |
>>> can all dream, can't we, so let's just do it(tm). |
48 |
>>> |
49 |
>>> I will try to carve a few roads in the sand in this mail that should |
50 |
>>> somehow reflect what I think the things to discuss are, if we really |
51 |
>>> want to get moving towards our holy grail. Considering [1], this |
52 |
>>> might |
53 |
>>> be all useless afterward, but ok. |
54 |
>>> |
55 |
>>> My personal targets for this project are as follows: |
56 |
>>> 1. Make Gentoo for OSX an acceptable sub-project of the Gentoo |
57 |
>>> family. |
58 |
>>> 2. Get a prefixed install to make Gentoo for OSX comparative to |
59 |
>>> Fink and |
60 |
>>> Darwin Ports, and quality wise go beyond. |
61 |
>> |
62 |
>> Why (2) is not first on everyones priority list, I really don't |
63 |
>> understand. If we can do (2) in a reasonably sane fashion, (1) will |
64 |
>> 'just happen'. |
65 |
>> |
66 |
>>> |
67 |
>>> Both two targets require some extra explanation. |
68 |
>>> 1. Gentoo for OSX functions as "black sheep" of the Gentoo |
69 |
>>> family. In |
70 |
>>> that way we put a spell on not only ourselves, but also on the |
71 |
>>> Gentoo/Alt project -- which is a good candidate for the second |
72 |
>>> black |
73 |
>>> sheep. It may be just that some people don't like the smell |
74 |
>>> of non |
75 |
>>> GNU/Linux stuff, but there are also constructive comments which |
76 |
>>> cannot be denied. |
77 |
>>> - My current stategy is to just show some goodwill, by for |
78 |
>>> instance |
79 |
>>> reacting swift and accurate to security bugs, as my |
80 |
>>> impression is |
81 |
>>> that those have been ignored in the past. But not only securty |
82 |
>>> bugs, all bugs where we get involved I try to react within |
83 |
>>> reasonable time, just to show we care. Well I do. Of |
84 |
>>> course any |
85 |
>>> support in this gets a warm welcome from me. |
86 |
>>> - In cooperation with others (mostly vapier) I try to reduce the |
87 |
>>> ebuild "spam" caused by ppc-macos. An example is the big |
88 |
>>> anti conditional bug [2] which unfortunately hasn't got much of |
89 |
>>> my attention yet. The idea is simple: make unconditional stuff |
90 |
>>> just to ease maintenance and keep ebuilds slim and pure. |
91 |
>>> 2. A prefixed install for me means having a way to install into |
92 |
>>> /Library/Gentoo, /Gentoo, /Users/Library/Gentoo or wherever. I |
93 |
>>> don't |
94 |
>>> really care about the location, and a system wide install |
95 |
>>> would be |
96 |
>>> fine with me too. I envision that a touch discussion on variable |
97 |
>>> prefixes, or homedir prefixes and whatever will follow if not yet |
98 |
>>> have been on the portage channels. What I would like to see is |
99 |
>>> that |
100 |
>>> we can play with it, maybe not in its ideal state, but those |
101 |
>>> improvements can be made while we're playing. |
102 |
>> |
103 |
>> My impression is everyone in the OS X team feels this is something |
104 |
>> thats going to get immaculately implemented by the portage gods, |
105 |
>> leaving us to reap the benefits.... not likely... If we don't do the |
106 |
>> work, no one will. I've been trying for months to no avail to get |
107 |
>> others involved so we can start 'playing with it'. Can lead a horse |
108 |
>> to water but can't make him drink I suppose... |
109 |
>> |
110 |
>>> - Although I have seen signals that we're close to something like |
111 |
>>> this (kudos to Kito and Brian) |
112 |
>> |
113 |
>> I have a self-hosting toolchain working in a prefix right now. Tons |
114 |
>> of bugs, tons of things not implemented yet, etc. etc. but its a |
115 |
>> solid start. Keep in mind, this should only be considered a proof-of- |
116 |
>> concept, mainly to help determine the requirements of the ebuilds |
117 |
>> when working in a prefixed environment. |
118 |
>> |
119 |
>> My rough plan is to squash a few of the major bugs left (collision- |
120 |
>> protect and binpkgs primarily), with brians help roll a new patch |
121 |
>> against current stable portage(using rc4 currently), check my overlay |
122 |
>> into the alt svn module, create a "developers preview" install pkg, |
123 |
>> and then continue adding ebuilds to the EAPI=1 overlay, adding |
124 |
>> features/bug squashing as we go. Once the overlay is in a fairly |
125 |
>> workable state, we can start/continue the beloved GLEP/Flaming |
126 |
>> process we all know and love. |
127 |
>> |
128 |
>> Brian has better insight than I on the long-term roadmap, so |
129 |
>> hopefully he'll chime in here, but my guess is the very very earliest |
130 |
>> we could see prefixed support in mainline would be around the time of |
131 |
>> saviours(3.0) official release... but in the meantime there is by no |
132 |
>> means any shortage of work to be done... |
133 |
>> |
134 |
>> All that being said, the more people working towards this same goal, |
135 |
>> the higher the probability of its success and eventual adoption by |
136 |
>> Gentoo proper. |
137 |
>> |
138 |
>>> in the mean-while I try to cope with |
139 |
>>> the bugfloods ;). Keywording the low-hanging fruit (those |
140 |
>>> ebuilds |
141 |
>>> with little or none USE-flags that just compile out of the box) |
142 |
>>> reduces the number of open bugs and should be ok when in a |
143 |
>>> prefix |
144 |
>>> too. Having more keyworded in portage prepares us a bit for |
145 |
>>> the |
146 |
>>> grand "Fink challenge" too. |
147 |
>>> - To reach a good quality we will have to reenable the normal |
148 |
>>> keywording scheme again. This will only be done once we have a |
149 |
>>> prefixed installer. From that point, the imlate scripts and |
150 |
>>> such |
151 |
>>> count for us too. Problem there is that we will have to |
152 |
>>> maintain |
153 |
>>> the whole tree, like for instance the AMD64 guys do. We're |
154 |
>>> outnumbered and hence I think we could use some extra devs that |
155 |
>>> have more free time on their hands than most of us now. |
156 |
>> |
157 |
>> Again, I think that once a product exists that is actually useful, |
158 |
>> both devs and users a like will start showing up...bit of a chicken/ |
159 |
>> egg situation I know, but this is opensource, without a strong |
160 |
>> userbase, we won't ever have a strong dev team. |
161 |
>> |
162 |
>>> |
163 |
>>> To conclude a short note on various flavours of the project, such as |
164 |
>>> progressive and darwin. I am not interested in those myself. My |
165 |
>>> main |
166 |
>>> focus is on the 'consumer product', which should be the mainline |
167 |
>>> product, or the collision-protect profiles as they are called now. |
168 |
>>> The |
169 |
>>> fact that I am not interested (yet) into these profiles, does not |
170 |
>>> mean I |
171 |
>>> will never support them. I would just like to focus on getting the |
172 |
>>> mainline (normal users) product going, then if people have a |
173 |
>>> personal |
174 |
>>> target to create a progressive profile for instance, I will not stop |
175 |
>>> such development -- not even wondering on how I would be able to |
176 |
>>> stop it |
177 |
>>> anyway. I consider one of my personal wishes for a 64-bit |
178 |
>>> install to |
179 |
>>> be a profile that should walk the same path like a progressive |
180 |
>>> profile: |
181 |
>>> it should wait till there is a working mainline product. |
182 |
>> |
183 |
>> To follow that logic, why are we continuing to mark things ~ppc-macos |
184 |
>> when we don't even have a working a mainline product? I look at the |
185 |
>> progressive profile about the same as you look at mass keywording for |
186 |
>> all of dirks bug reports..."Its not extremely useful right now, but |
187 |
>> the work will have to be done at some point, so why not now?" |
188 |
>> |
189 |
>> Building a prefixed stage1 went extremely quickly because most of the |
190 |
>> base-system packages had already been ported to OS X via my work with |
191 |
>> the base-system people(ok, mainly just spanky ;) on the progressive |
192 |
>> profile(perl,bash,coreutils,gcc- |
193 |
>> apple,flex,bison,python,auto*,texinfo,zlib,bzip2,rsync, etc. etc.). |
194 |
>> This attitude of 'we only support the consumer product' is a good |
195 |
>> outward goal, but is also what IMHO contributed to the half-assed |
196 |
>> nature of the current collision-protect profiles...i.e. "We have a |
197 |
>> very short sighted implementation, that is a maintenance nightmare, |
198 |
>> requires very heavy modifications to the tree, and has virtually 0 |
199 |
>> appeal to both devs and users, but lets keep working hard and try to |
200 |
>> get gaim and x-chat keyworded ppc-macos because its what users want." |
201 |
>> |
202 |
>> What I'm saying is, darwin and progressive provide a testbed for the |
203 |
>> bottom-up approach that we should have been taking from the |
204 |
>> beginning. |
205 |
>> |
206 |
>> --Kito |
207 |
>> -- |
208 |
>> gentoo-osx@g.o mailing list |
209 |
>> |
210 |
>> |
211 |
> |
212 |
> -- |
213 |
> gentoo-osx@g.o mailing list |
214 |
> |
215 |
|
216 |
-- |
217 |
gentoo-osx@g.o mailing list |