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