Gentoo Archives: gentoo-ppc-dev

From: Pieter Van den Abeele <pvdabeel@g.o>
To: gentooppc-dev@g.o
Subject: Re: [gentooppc-dev] ARCH=ppc in unified portage and some downfalls
Date: Mon, 10 Jun 2002 16:15:49
Message-Id: Pine.LNX.4.44.0206101543510.12515-100000@chiba.3jane.net
In Reply to: Re: [gentooppc-dev] ARCH=ppc in unified portage and some downfalls by mguertin@macdiscussion.com
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 >

Replies