| 1 |
On 19-04-2008 15:31:35 +0200, Bacchella Fabrice wrote: |
| 2 |
>> So the alternative is to switch from arch to ~arch in the post-sync |
| 3 |
>> stage. Thoughts here? |
| 4 |
>> |
| 5 |
>> Questioni is now how are we going to implement this, if we all agree |
| 6 |
>> this is the way to go? Do we agree in the first place? |
| 7 |
> |
| 8 |
> I think that's a good idea. In the last 2/3 weeks, I had too many problems |
| 9 |
> with package upgrading while I was building. |
| 10 |
> |
| 11 |
> I don't know if having to upgrade all system package is a big deal. For |
| 12 |
> example, there is a lot of /usr/sfw/lib in RUNPATH left over for the |
| 13 |
> solaris build. So a re-emerge is a good thing anyway. And there a lot of |
| 14 |
> package to get after the boot strap, so it's going to be a long process |
| 15 |
> anyway. |
| 16 |
|
| 17 |
Method A: |
| 18 |
emerge a b c |
| 19 |
emerge --sync |
| 20 |
emerge -u system |
| 21 |
emerge -e system |
| 22 |
echo 'ACCEPT_KEYWORDS="~arch"' >> make.conf |
| 23 |
emerge -e system |
| 24 |
|
| 25 |
Method B: |
| 26 |
emerge a b c |
| 27 |
emerge --sync |
| 28 |
emerge -u system |
| 29 |
echo 'ACCEPT_KEYWORDS="~arch"' >> make.conf |
| 30 |
emerge -e system |
| 31 |
|
| 32 |
|
| 33 |
Method A has the clear advantage that you'll much more likely make it to |
| 34 |
the end of the bootstrap document, however once you decide you want to |
| 35 |
do more than just system packages (quite likely), you'll basically |
| 36 |
confronted with the entire system set having newer versions (gcc, |
| 37 |
binutils, python, coreutils, to name a few larger ones). |
| 38 |
|
| 39 |
Method B is more risky, but should work if we manage not to break the |
| 40 |
life tree, which in theory shouldn't happen, but in practise not always |
| 41 |
is. Though should be easy to recover from that using emerge --sync. |
| 42 |
|
| 43 |
|
| 44 |
-- |
| 45 |
Fabian Groffen |
| 46 |
Gentoo on a different level |
| 47 |
-- |
| 48 |
gentoo-alt@l.g.o mailing list |
Archives