| 1 |
On Saturday 06 April 2002 12:20, you wrote: |
| 2 |
> I'm fixing the problem (below) as we speak :-) Updated portage will be |
| 3 |
> available within the hour: |
| 4 |
> |
| 5 |
> *fixed some typos in your ppc kernel ebuilds |
| 6 |
> *grep DEPEND * -r | grep kernel revealed some ebuild were depending on x86 |
| 7 |
> kernels. (ll remove x86 kernels from ppc portage :-) ) |
| 8 |
> *fixed some ppc-related digests |
| 9 |
> *glibc DEPENDs has special kernel requirements... fixing that mess too |
| 10 |
> |
| 11 |
> > portage merges, then it proceeds to emerge |
| 12 |
> > sys-kernel/linux-headers-2.4.17-r5, downloads |
| 13 |
> > http://mirrors.sunsite.dk/gentoo/distfiles/linux-2.4.17.tar.bz2 and |
| 14 |
> > http://mirrors.sunsite.dk/gentoo/distfiles/linux-2.4.17-r5.patch.bz2 to |
| 15 |
> > the proper distfiles directory, but when it tries to unpack |
| 16 |
> > linux-2.4.17.tar.bz2, portage hangs. if i interrupt the process, i get: |
| 17 |
> > |
| 18 |
> > !!! Portage interrupted by SIGINT; exiting. |
| 19 |
> > |
| 20 |
> > *** Unpack Aborted *** |
| 21 |
> > |
| 22 |
> > if i restart the process, portage still hangs. |
| 23 |
> > |
| 24 |
> > is the portage-1.8.12 functional? are my make.conf settings wrong? |
| 25 |
> > where could the problem be? thanks... |
| 26 |
|
| 27 |
I updated ppc portage/sys-kernel: |
| 28 |
|
| 29 |
I decided to remove all non ppc kernel ebuilds, to make things easier to work |
| 30 |
with. This makes our tree a bit cleaner and makes possible future merging |
| 31 |
into gentoo(x86) portage easier. |
| 32 |
|
| 33 |
I analysed the bootstrap problem and came to the following conclusion: |
| 34 |
Various ebuild were depending on sys-kernel/linux-source. When further |
| 35 |
analysing sys-kernel I noticed 2.4.19 ebuild had some typos (wrong location |
| 36 |
of the patch (gentoo should have been gentooppc)) and 2.4.19 in linux-sources |
| 37 |
was the x86 one. 2.4.17-r5 was being emerged by this users installation right |
| 38 |
after portage got emerged. There's no ebuild depending on 2.4.17, so I |
| 39 |
suppose it must have been baselayout (the first ebuild after portage to be |
| 40 |
emerged in bootstrap that caused 2.4.17-r5 to be emerged) |
| 41 |
|
| 42 |
Baselayout was depending on sys-kernel/linux-headers. So 2.4.17-r5 should |
| 43 |
have been emerged right there. Which is very strange because there was a |
| 44 |
2.4.19 ebuild in linux-headers (it shoud have been, because it is in cvs and |
| 45 |
right before bootstrap is run, portage should be up to date). I suppose the |
| 46 |
user was using a very old portage (without 2.4.19), that was not suited for |
| 47 |
ppc. |
| 48 |
|
| 49 |
I removed all X86 kernel ebuilds and only kept the 2.4.19 ppc ebuild in both |
| 50 |
headers/sources and ppc-sources. I also (temporarily) masked <=2.4.18 so the |
| 51 |
ppc patched 2.4.19 should be used next time. |
| 52 |
|
| 53 |
I think it would be best to remove sys-kernel/linux-ppc-sources and place |
| 54 |
ppckernels in sys-kernel/linux-sources and sys-kernel/linux-header. I'm |
| 55 |
thinking of adding a "ppc" USE (or maybe a new ARCH flag) variable to gentoo |
| 56 |
that would instruct ebuilds to patch the software they are installing with |
| 57 |
ppc patches. |
| 58 |
|
| 59 |
Maintaining the gentooppc port would be much easier because instead of |
| 60 |
continuously adding ebuilds added to x86 to ppc, we should only be patching |
| 61 |
whenever a user reports a problem with ebuilds added to x86 portage or |
| 62 |
whenever X86portage releases a new kernel/compiler. PPC specific software |
| 63 |
like yaboot, hfs utils etc would only be mergeable if ppc USE/ARCH flag is |
| 64 |
set. Other software like lilo, grub would only be mergeable if for example |
| 65 |
ARCH=x86 or ppc USE is not set. This would probably make ppc gentoo a little |
| 66 |
more unstable. Do you think this is possible? x86 ebuilds would be |
| 67 |
automatically compatible with ppc, unless they require a certain ARCH/USE |
| 68 |
Pseudocode of ebuilds: |
| 69 |
|
| 70 |
--- |
| 71 |
lilo.ebuild: |
| 72 |
require (arch==x86) { |
| 73 |
install lilo |
| 74 |
} |
| 75 |
--- |
| 76 |
|
| 77 |
--- |
| 78 |
kde.ebuild: |
| 79 |
install kde |
| 80 |
--- |
| 81 |
|
| 82 |
--- |
| 83 |
gcc.ebuild: |
| 84 |
download sources |
| 85 |
if (ARCH==ppc) { |
| 86 |
download ppc patch |
| 87 |
patch gcc |
| 88 |
} |
| 89 |
install sources |
| 90 |
--- |
| 91 |
|
| 92 |
--- |
| 93 |
kernel.ebuild: |
| 94 |
download sources |
| 95 |
if (ARCH==ppc) { |
| 96 |
download ppc patch |
| 97 |
patch kernel |
| 98 |
} |
| 99 |
else if (ARCH==x86) { |
| 100 |
download x86 patch (preempt, ac etc) |
| 101 |
patch kernel |
| 102 |
} |
| 103 |
else { |
| 104 |
end 1 "unknow arch" |
| 105 |
} |
| 106 |
install kernel |
| 107 |
--- |
| 108 |
|
| 109 |
Or should we maintain two different portages and have portage ppc a bit |
| 110 |
outdated? Maintaining two different portages has some advantages too: |
| 111 |
gentooppc is stable (portage does not contain software that cannot be |
| 112 |
installed on ppc). |
| 113 |
|
| 114 |
In any case CVS access to x86 portage would be great :-) |
| 115 |
|
| 116 |
regards |
| 117 |
|
| 118 |
-- |
| 119 |
Pieter Van den Abeele |
| 120 |
pvdabeel@××××××.be |
Archives