1 |
On Thu, Oct 27, 2016 at 9:27 PM, Kent Fredric <kentnl@g.o> wrote: |
2 |
> On Thu, 27 Oct 2016 09:21:06 -0400 |
3 |
> Rich Freeman <rich0@g.o> wrote: |
4 |
> |
5 |
>> I'm not saying you can completely avoid the need for having some kind |
6 |
>> of bootstrapping stage1. I'm just saying we should separate that need |
7 |
>> from the issue of fully specifying dependencies, at least in an ideal |
8 |
>> world where we're unconcerned with the effort of specifying |
9 |
>> dependencies. |
10 |
> |
11 |
> I think you could partially solve this by having gentoo-built binaries |
12 |
> of things that are needed for bootstrap shipped as sys-devel/gcc-bin, |
13 |
> or similar. |
14 |
|
15 |
Well, for gcc that would probably work, though I think it would make |
16 |
more sense to just have a binary package of gcc and not a different |
17 |
package under a different name. I'd actually extend that to other |
18 |
-bin packages we already have, like libreoffice-bin (assuming we build |
19 |
that ourselves). For the case of an upstream binary the distinction |
20 |
is probably worthwhile, but for a package we build ourselves it makes |
21 |
a lot more sense to just let portage build a binary package and |
22 |
install it. |
23 |
|
24 |
However, this still wouldn't eliminate the need for a stage1 set |
25 |
because just to install a binary package you do need a small number of |
26 |
components, like portage, bash, glibc, tar, bzip2, and so on. |
27 |
|
28 |
I believe the way catalyst works is that it uses the host system to |
29 |
build the stage1 packages and install them into the chroot. Then from |
30 |
there it can run inside the chroot to build stage2 and stage3. All |
31 |
the packages are built fresh, but the stage1 is built in the host |
32 |
environment, not the target environment. |
33 |
|
34 |
-- |
35 |
Rich |