1 |
On Tue, 2005-08-30 at 11:24 -0400, Stephen P. Becker wrote: |
2 |
> >>Is this also a good time to note that the amd64 and x86 could |
3 |
> >>*easily* be covered under the same keyword? We cover a large |
4 |
> >>variety of mips machines/userlands under one keyword, with |
5 |
> >>differences much more significant then that between x86 and amd64. |
6 |
> > |
7 |
> > |
8 |
> > Sorry I disagree with this, differences exists and sometimes are a |
9 |
> > problem. Some package and library don't compile cleanly under amd64 arch. |
10 |
> > On few but existant cases it's good to have two different archs. Not |
11 |
> > even going near the analizing the differences in the profiles. |
12 |
> |
13 |
> So these things won't compile in a x86 chroot on a amd64 box even? I |
14 |
> find that really hard to believe. Besides, close collaboration between |
15 |
> folks with x86 and folks with amd64 installs can make it easy to ensure |
16 |
> the same versions work on both arches (if you really want to call them |
17 |
> separate arches...) Your profile argument is silly too, since both |
18 |
> arches could *easily* be merged into sub-profiles in our cascading system. |
19 |
> |
20 |
> Besides, we have the same sorts of problems on mips, except they are |
21 |
> magnified since we have a possibility of 3 different userland ABIs, on |
22 |
> both big and little endian hardware. After dealing with this sort of |
23 |
> stuff for a long time with *far* fewer developers and time in general, |
24 |
> I'm really not impressed with your argument. You'll have to do better |
25 |
> then that. |
26 |
> |
27 |
> -Steve |
28 |
|
29 |
I agree that merging the two profiles is something to aspire to (see the |
30 |
recent ppc/ppc64 profile merge as an example. However merging the |
31 |
keywords can lead to trouble. Speaking only for ppc/ppc64 there are |
32 |
times when there are very specific ppc64 compiler problems that, if we |
33 |
shared a keyword, leave a large portion of the tree keyworded for |
34 |
stability but in a "You can only compile this program in a 32-bit |
35 |
chroot" state. I would rather make a clear cut statement that these apps |
36 |
only function in a 32-bit env then give the user the impression that |
37 |
they work "out of the box". |
38 |
|
39 |
Take for example Mozilla, Firefox, and OpenOffice none of these function |
40 |
on ppc64 (yet) but they function without issue on ppc. It is only within |
41 |
the last few months that Mozilla even got a ~ppc64 keyword (and not |
42 |
because it works, all it does at the moment is launch a window). |
43 |
|
44 |
Just to give you an idea. Last I looked (a week or so ago) the number of |
45 |
ppc stable keyworded packages outnumbered the ppc64 ones by almost 3:1. |
46 |
Now some of this is just due to a lack of manpower to test all those |
47 |
packages, and some of it is due to a lack of end-user interest in those |
48 |
packages on the ppc64 platform but I can guarantee that some of them |
49 |
also suffer ppc64 specific bugs. Until the stable list matches at least |
50 |
90% I personally would be unwilling to merge the keywords. If we ever |
51 |
get to that point I think the remaining packages could be dealt with on |
52 |
a case by case basis when users tripped over them. After that we could |
53 |
deal with new packages in a coordinated way making sure that they work |
54 |
on both platforms together. |
55 |
|
56 |
I also don't buy the argument that the user has to be educated on how to |
57 |
change their ABI midstream if something breaks under one or the other on |
58 |
a mainstream arch. I am of the stong opinion that things should just |
59 |
work, 100% of the time. That means that for each set (ppc/ppc64 & |
60 |
x86/amd64) the ebuilds have to be gone over and modified to use the |
61 |
appropriate abi internally. Mips is slightly different as it is a niche |
62 |
architecture with a smaller, arguably better educated in the ways of gcc |
63 |
etc., user base. |
64 |
|
65 |
I don't know what the ratio is for amd64 and x86 (I suspect far better |
66 |
then ppc64 vs. ppc as the dev/user base is far larger) but I think that |
67 |
it is something to move towards if the ratio is close enough even if it |
68 |
means denying some functionality to one group or the other until some |
69 |
bugs are solved. |
70 |
|
71 |
|
72 |
-- |
73 |
Daniel Ostrow |
74 |
Gentoo Foundation Board of Trustees |
75 |
Gentoo/{PPC,PPC64,DevRel} |
76 |
dostrow@g.o |
77 |
|
78 |
-- |
79 |
gentoo-dev@g.o mailing list |