1 |
Hi Pieter |
2 |
|
3 |
Well i can see your points on things, but here\'s where the single |
4 |
biggest porblem lies. The x86 gentoo had no less than 22 updated ebuilds |
5 |
comitted last week, of which only ONE was tested on ppc (Azarah is good |
6 |
for that - he asked me to test it) becuase it containted some very long |
7 |
awaited PPC fixes (was the scrollwheel fix for xfree). This also bring |
8 |
to point the fact that this build _just_ made it live with some crucial |
9 |
ppc fixes after weeks of waiting. |
10 |
|
11 |
It is still my opinion that a unified tree is going to cause many many |
12 |
many problems in the very near future (like with GCC 3.1). No offence |
13 |
to the gentoo folk but there are truly some _bad_ x86 developers |
14 |
comitting completely untested code and unmasking things that just |
15 |
shouldn\'t be. |
16 |
|
17 |
For example I did an updated qt-copy snapshot build last week w/ fixes |
18 |
for both ppc and x86, and I put it up for testing (masked), the |
19 |
maintainer unmasked it within one hour of when I committed it with no |
20 |
testing and it broke things for some people because of this. It makes |
21 |
us (me) look bad, it was a simple fix that and I got in it right away, |
22 |
but you see where things are leading to here... |
23 |
|
24 |
There are _very_ many things in the current portage which have a lot of |
25 |
x86 specific stuff in them (i.e. tweaked config files, x86 only |
26 |
patche,s, etc) and honestly i don\'t think that we can either rely onthe |
27 |
x86 devs to test things against ppc, nor should they really have to in a |
28 |
perfect world. |
29 |
|
30 |
portage really really needs something better than if [ ${ARCH} = \"ppc\" |
31 |
] for the environment. As for the xforms fiasco i can fill you in in |
32 |
private, but hold on to your shorts, its a _very_ nasty problem that is |
33 |
not likely to get resolved in the near future. |
34 |
|
35 |
My biggest concern is there will be much fighting between x86 peeps and |
36 |
ppc peeps to make things happen, in the last few weeks since you |
37 |
haven\'t been around the x86 portage has literally exploded with new |
38 |
builds, and if you go to the #gentoo channel at all it appears that |
39 |
there are a LOT of broken things. In fact on my x86 box right now (even |
40 |
with cvs tree) there are a lot of things that just plain don\'t work, |
41 |
and becuase of this the ppc version of things will also be broken. |
42 |
|
43 |
I also posted this message to gentoo-core (are you a member of that |
44 |
list?) and got at least an answer from drobbins. I think we will ahve |
45 |
to work with him on getting portage a lot more ARCH friendly, or we are |
46 |
going to have a lot of problems getting things done. |
47 |
|
48 |
havin x86 and ppc within the exact same file is a nightmare from where i |
49 |
see it, but if that is the way things need to be then that is how it |
50 |
will be I guess. PPC != x86 for maturity level or code compatability. |
51 |
i would love to see a .ppc.ebuild file as a seperate entity, but that\'s |
52 |
just me. it would solve many problems. |
53 |
|
54 |
I also think that one of the first things we have to do with the ppc |
55 |
portage is to mask ot _everything_ that is in x86 portage, and then |
56 |
proceed to unmaks only certified things that work. There are still many |
57 |
things in portage that might not work, but no ones knows as they have |
58 |
probably not even been tried on ppc to this point in time. |
59 |
|
60 |
I honestly think that Gentoo needs some \'port\' managers, I.E. people |
61 |
doing QA that can verify that things are proper before things actually |
62 |
get comitted to the public portage, it doesn\'t make sense any other |
63 |
way. Right now peeps can commit wahtever they want and within 30 |
64 |
minutes it\'s live! That is scary as ehll from where i see it...for |
65 |
example someone accidentily comitted their hacked up packages.mask file |
66 |
which opened up a whole bevy of stuff to the world and it went for a day |
67 |
before anyone noticed it (eeeeeek). |
68 |
|
69 |
Gerk |
70 |
|
71 |
P.S. i think we are trying to get an IRC meeting toegether of the PPC |
72 |
peeps, we did it last week as well, but had a poor turnout :( (3 peeps |
73 |
were there). i think that we should try and get this going ASAP and |
74 |
also invite drobbins in (i think he discussed wanting to meet with us on |
75 |
IRC as well). |
76 |
|
77 |
P.S.S. If you would like to test some things I can arrange a shell |
78 |
account for you on a PPC box and give you root access until you are up |
79 |
and running again. Email me privately if you want this :) |
80 |
|
81 |
|
82 |
On 06-10-2002 06:00 am, you wrote: |
83 |
|
84 |
> Hi, |
85 |
> |
86 |
> On Sun, 9 Jun 2002, Owen Stampflee wrote: |
87 |
> |
88 |
> > Well, as I have said in IRC, I believe that creating a new rsync |
89 |
tree |
90 |
> > would fix things for the moment. We could always have a testing tree |
91 |
for |
92 |
> > those who want to use err test, err blow up their systems with the |
93 |
> > latest packages. |
94 |
> |
95 |
> > Debian does it this way, keeping all the different archs seperate. |
96 |
With |
97 |
> > a binary packaging method it has to be done this way so why isnt |
98 |
this |
99 |
> > done when the packages are in source form? This would solve little |
100 |
> > problems such as xforms and we could also fix other little things |
101 |
which |
102 |
> > say they require nasm but don\'t really need it. |
103 |
> > |
104 |
> > In the future it would be great if portage could do this |
105 |
automagically. |
106 |
> > It could look at the arch and then pull from the correct tree. |
107 |
> > |
108 |
> > Owen |
109 |
> |
110 |
> Gentoo is not Debian :-) |
111 |
> |
112 |
> When GentooPPC was born it had it\'s own CVS and rsync, because of |
113 |
this, |
114 |
> there was a lot of QA (which seems to be a major factor now): |
115 |
GentooPPC |
116 |
> CVS (and rsync) was about a week \'behind\' on x86 CVS. There were a |
117 |
few |
118 |
> major problems: |
119 |
> |
120 |
> 1) Ebuilds could be broken on both PPC and x86, when x86 devs |
121 |
introduced |
122 |
> a rewrite/cleanup, it had to be manually imported on PPC. Most of the |
123 |
time |
124 |
> ppc devs don\'t know when a bugfix is introduced to x86 portage, so |
125 |
it |
126 |
> happened often that ppc users reported a bug already fixed on x86. |
127 |
> |
128 |
> 2) If an ebuild is fixed on PPC, it has to be introduced to x86 at |
129 |
the |
130 |
> same time. Introducing stuff to x86 shouldn\'t happen without testing |
131 |
on |
132 |
> x86, if the x86 part stopped working, it needs to get |
133 |
> fixed, and the fixed x86 ebuild may stop working on ppc ... |
134 |
> Combined with another arch merging its stuff at the same time, makes |
135 |
life |
136 |
> very interesting: ppc stuff is fixed against x86 ebuilds, if for |
137 |
example |
138 |
> sparc introduced a fix to x86, the ppc fix is rendered invalid, and |
139 |
has to |
140 |
> be completely rewritten to accomodate the sparc fix. Of course this |
141 |
caused |
142 |
> ppc patches to be added to x86 often without testing. |
143 |
> |
144 |
> The merge into x86 could introduce a few problems: a newer |
145 |
> release may have been introduced on x86 or the x86 ebuild may have |
146 |
had |
147 |
> some other things fixed, the newer ebuilds have to be merged into |
148 |
PPC, |
149 |
> fixed and tested again and again, until the ebuild on ALL platforms |
150 |
> works. Most ppc guys don\'t have a x86 and a sparc at home to test. |
151 |
(I |
152 |
> have only an x86 which is running Gentoo) |
153 |
> |
154 |
> 3) While an ebuild might look the same, it may be different on two |
155 |
> platforms. Finding out which one is newer is easy to do, making sure |
156 |
the |
157 |
> newest ebuild works on both platforms requires testing. |
158 |
> |
159 |
> 4) Importing stuff from x86 into PPC portage (syncing the two) is |
160 |
almost |
161 |
> impossible to do with CVS (It will still remain more or less |
162 |
impossible |
163 |
> when we start using bitkeeper for example) |
164 |
> |
165 |
> 5) Fixes introduced by the PPC platform in X86 may be \'forgotten\' in |
166 |
newer |
167 |
> releases on x86. No x86 dev is able to test the ppc fix, so ppc |
168 |
fixes |
169 |
> might seem unnecessary... |
170 |
> |
171 |
> 6) x86 devs tend to shit ebuilds directly into x86 portage |
172 |
> |
173 |
> 7) Every day new ebuild features get added to portage: new USE |
174 |
> vars, old USE vars get removed, new SLOT var, new LICENCE var, |
175 |
ebuild |
176 |
> indentation rules... I have no problem with introducing and removing |
177 |
> features, or even rewriting the whole portage stuff, but it is |
178 |
almost |
179 |
> impossible to merge stuff between trees when these things happen. |
180 |
That\'s |
181 |
> why I want to keep a single tree containing all. This way ppc fixes |
182 |
get fo |
183 |
> |
184 |
> Keeping a separate repository for all archs might seem a good idea, |
185 |
it |
186 |
> isn\'t because this will cause gentoo to fall apart, and |
187 |
> multiplies all work by 5 and might even render the work unusable |
188 |
after |
189 |
> all. |
190 |
> |
191 |
> Debian may be able to use separate trees, but there are a lot more |
192 |
devs |
193 |
> working on Debian and I chose Gentoo because Debian would rather fix |
194 |
old |
195 |
> packages than introduce new ones. I want to be on the edge, and |
196 |
compile |
197 |
> everything from source, but this doesn\'t mean Gentoo cannot be as |
198 |
stable |
199 |
> like debian-stable. |
200 |
> |
201 |
> With Gentoo stability is achieved by emerging a basic system, and |
202 |
> emerging newer ebuild releases when critical bugs are detected in |
203 |
the |
204 |
> software merged by the ebuild (this can be done using a profile, but |
205 |
the |
206 |
> profile has to be maintained). Gentoo needs to do QA by |
207 |
<<<testing>>> |
208 |
> more before releasing. No more: |
209 |
> |
210 |
> voila, it\'s in portage, please try it out |
211 |
> |
212 |
> But: |
213 |
> |
214 |
> voila, it\'s in portage, unmask it (merge with -unstable or whatever) |
215 |
and |
216 |
> it will be unmasked when it\'s tested by a few people. |
217 |
> |
218 |
> I\'m sure we will see a Gentoo-stable solution soon. |
219 |
> But please bear in mind that Gentoo is an all-in-one solution and I |
220 |
> think it should stay that way. A linux distro can be stable and on |
221 |
the |
222 |
> edge at the same time, it\'s up to the user to choose what ebuilds |
223 |
he |
224 |
> likes, just like debian, but with a single repository for all archs, |
225 |
this |
226 |
> allows people to be on the edge on all platforms and allows devs to |
227 |
> concentrate on testing instead of merging untested. This doesn\'t |
228 |
mean |
229 |
> there can\'t be a Gentoo-stable (profile or whatever) on all archs. |
230 |
> |
231 |
> > problems such as xforms and we could also fix other little things |
232 |
which |
233 |
> > say they require nasm but don\'t really need it. |
234 |
> |
235 |
> Due to some techical failure on one of my critical boxes, I have been |
236 |
away |
237 |
> a while, so I\'m not up to speed with what happened with xforms and |
238 |
other |
239 |
> related discussions. |
240 |
> |
241 |
> I guess that ebuilds that require nasm but don\'t really need it can |
242 |
have |
243 |
> the nasm dependency removed. (or it should be merged with nasm use |
244 |
flag |
245 |
> removed, if a nasm flag exists) |
246 |
> |
247 |
> It reminds me of the vim problem that had X as a dependency, mergin |
248 |
vim |
249 |
> meant merging X. It should be split up into two ebuilds or you should |
250 |
be |
251 |
> able to disable the X compilation dependency by removing the X |
252 |
useflag. |
253 |
> |
254 |
> If the ebuild is really broken, it can be masked out in the profile |
255 |
(just |
256 |
> like lilo for example, which has no use on ppc), until some ppc dev |
257 |
> rewrites the ebuild or patched it. |
258 |
> |
259 |
> Pieter |
260 |
> |
261 |
> -- |
262 |
> Pieter Van den Abeele |
263 |
> pvdabeel@××××××.be - pvdabeel@g.o |
264 |
> |
265 |
> > -- |
266 |
> > Owen Stampflee - owen@××××××××××.org |
267 |
> > http://penguinppc.org/~owen |
268 |
> > |
269 |
> > _______________________________________________ |
270 |
> > gentooppc-dev mailing list |
271 |
> > gentooppc-dev@g.o |
272 |
> > http://lists.gentoo.org/mailman/listinfo/gentooppc-dev |
273 |
> > |
274 |
> |
275 |
> _______________________________________________ |
276 |
> gentooppc-dev mailing list |
277 |
> gentooppc-dev@g.o |
278 |
> http://lists.gentoo.org/mailman/listinfo/gentooppc-dev |