[gentoo-dev] gentoo ppc

[Debian User Jean-Baptiste Note]

Hello

I'm glad to announce that emerge system works for (almost)all packageson ppc.
>From these I have to substract the x86-specific packages. and iproute2,
that gives me some problems maybe because of -Werror only.
I have kept good record of the steps i took.

Just to introduce myself, i'm 22 years old, a student in a French engeneering
school. Although I have been using a computer for some time now, and debian linux
for a little more than one year, i must say i'm no linux expert.
I have very little experience in development for instance, but i'm willing
and hopefully able to learn fast :)

>From this comes two points :
1/ gentoo is extremely flexible. Port isnt hard, or i wouldn't have succeeded
in advancing so much. I never delved into portage, and barely edited some .ebuilds files.
I have gathered enough information so that i can write a gentoo-porting howto
from a working debian install, that can work as a base for an alpha port,
for instance, that should not be hard either.
Thank you for the great job of Gentoo in the first place !

2/ I am willing to do some modifications to portage to allow more cross-platform
flexibility. But, it obviously needs to be concerted.
So i'm gonna tell you boringly of the problems i encountered and some solutions
that i though of.

Problems are
a) platform-specific patches (gcc, patch itself)
b) platform-specific options (for instance, a `use altivec` one for
powerpc processors)
b) platform-specific packages (bootloaders for instance)

b)
I think portage needs a little tweaking i'm willing to do.
this would go thus (let's take the function src_uncompress as an exemple)
* look in the .ebuild for a platform-specific function to be executed
if it exists. 
* if src_uncompress_ppc exists on my ppc machine,
then execute it regardless of the existence of src_uncompress
* if no such platform-specific function is found, then
fallback on scr_uncompress.

This would allow a smooth transition :
--existing .ebuild files still work, and a default behaviour
is given to the platform-specific packagers
--you can still "factorize" platform-independent instructions
in the scr_uncompress function, and call it in the platform-specific
function
--ppc/alpha developers can safely work on their specific part
without endangering the x86 part

It would be nice, too, if some ${ARCH} variable computed by portage
was available to the .ebuild writer.

a)
The problem is that you don't necessarily want the x86 user to download
a ppc-spceific patch.
then you could define a SCR_URI_X86 SRC_URI_PPC additional to the already
existant SRC_URI if the ${ARCH} is matched. Better hide it in portage
than in a ugly if statement in the .ebuild file, i think (once again,
code factorization)

c)
I should think that platform-dependent utilities are not so much needed.
well, apart from x86 assembly compiler and bootloaders, that is :)
the answer, generally speaking, is virtual packages, if all platform can
provide their version of one tool. (ybin as bootloader for instance)
this is certainly the most difficult part, and i haven't given it much
though.

One more personal remark, not to bother you with my life, but :
i'm still a student, and do not have a hell of time :(
that'll be worse even after i suppose anyways.
Things i want to do
*solve the platform-specific-packages design problem
*write a gentoo-bootstrap-from-debian howto to help support other architectures (alpha ?)
*package ybin ? not really necessary, since most will dual-boot or
work chrooted
*hack portage. i'm learing python (not so tough :) and will look into
portage. but to implement, things need to be settled.

I'm done. I didn't know how to introduce myself, if i may sound awkward or
anything, please do not heed.
(My mastering of the English language is not good, either).

Thank you for your time, Jean-Baptiste Note.

-- 
I'm an occurence of the I love GNU virus.
Please help me spread.