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