[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Commented packages in the @system set
From:       Rich Freeman <rich0 () gentoo ! org>
Date:       2016-10-28 1:49:12
Message-ID: CAGfcS_=vPFoz6mvh0gJfcwd4PFe4dC8LzxF6dctM0_sw2SRwYw () mail ! gmail ! com
[Download RAW message or body]

On Thu, Oct 27, 2016 at 9:27 PM, Kent Fredric <kentnl@gentoo.org> wrote:
> On Thu, 27 Oct 2016 09:21:06 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> I'm not saying you can completely avoid the need for having some kind
>> of bootstrapping stage1.  I'm just saying we should separate that need
>> from the issue of fully specifying dependencies, at least in an ideal
>> world where we're unconcerned with the effort of specifying
>> dependencies.
>
> I think you could partially solve this by having gentoo-built binaries
> of things that are needed for bootstrap shipped as sys-devel/gcc-bin,
> or similar.

Well, for gcc that would probably work, though I think it would make
more sense to just have a binary package of gcc and not a different
package under a different name.  I'd actually extend that to other
-bin packages we already have, like libreoffice-bin (assuming we build
that ourselves).  For the case of an upstream binary the distinction
is probably worthwhile, but for a package we build ourselves it makes
a lot more sense to just let portage build a binary package and
install it.

However, this still wouldn't eliminate the need for a stage1 set
because just to install a binary package you do need a small number of
components, like portage, bash, glibc, tar, bzip2, and so on.

I believe the way catalyst works is that it uses the host system to
build the stage1 packages and install them into the chroot.  Then from
there it can run inside the chroot to build stage2 and stage3.  All
the packages are built fresh, but the stage1 is built in the host
environment, not the target environment.

-- 
Rich

[prev in list] [next in list] [prev in thread] [next in thread]