1 |
Due to numerous occasions of b0rkerage in the bootstrap snapshots, |
2 |
bootstrapping has failed. A selection of issues that come up: |
3 |
- XXXX/YYYYY-p.q is the latest version in the snapshot, but this version |
4 |
has been removed, and its distfiles have become unavailable (e.g. |
5 |
rsync-3.0.0_pre2) |
6 |
- XXXX/YYYYY-p.q was added in the snapshot, but breaks several packages |
7 |
(e.g. gcc-4.3.0) |
8 |
|
9 |
Because bootstrapping is just the preparatory step to your Prefix |
10 |
installation, it need not to be bleeding edge, and preferably it just |
11 |
works, of course. Keep in mind that the snapshots are used for the |
12 |
first `emerge system`, after that an emerge --sync is run and hence |
13 |
the life tree is used for the final `emerge -e system`. The pre-sync |
14 |
stage is the trickiest part, since it heavily relies on a correct order |
15 |
of things, correct dependendies and working packages. The post-sync |
16 |
stage is slightly less dramatic, since in principle the Prefix system is |
17 |
already functional at that stage. |
18 |
|
19 |
To aid the pre-sync stage, I am considering to switch to usign stable |
20 |
keywords for the system packages *only*. That is, the bootstrap process |
21 |
is done with stable keywords, all other packages remain ~arch and hence |
22 |
a user has to add ~arch to ACCEPT_KEYWORDS after bootstrapping finishes. |
23 |
|
24 |
There is one thing that I don't quite like: |
25 |
switching from arch to ~arch means after `emerge -e system` nearly any |
26 |
system package needs to be updated, that is quite a shame |
27 |
|
28 |
So the alternative is to switch from arch to ~arch in the post-sync |
29 |
stage. Thoughts here? |
30 |
|
31 |
Questioni is now how are we going to implement this, if we all agree |
32 |
this is the way to go? Do we agree in the first place? |
33 |
|
34 |
|
35 |
-- |
36 |
Fabian Groffen |
37 |
Gentoo on a different level |
38 |
-- |
39 |
gentoo-alt@l.g.o mailing list |