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