Gentoo Archives: gentoo-user

From: Rich Freeman <rich0@g.o>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] slot conflict for the same package: how to add a USE flag?
Date: Thu, 21 May 2020 12:34:35
Message-Id: CAGfcS_k3Bzce+cXoxON0kzG_1eN1EsJSdxiPxevf7aTh_ewrqQ@mail.gmail.com
On Thu, May 21, 2020 at 4:46 AM Thomas Mueller <mueller6724@×××.com> wrote:
> > > from n952162: > > > > And really unless you REALLY care about your CFLAGS you get 99% of the > > > benefit just sticking with the original stage3 and just rebuilding > > > anything you change USE flags for. Over time it will all get rebuilt > > > anyway using your preferences. > > > If I understand that correctly, using the stage3 tarball will give me a > > fully functioning system from binaries, but I can convert that in one > > fell swoop into sources by re-emerging everything, saving me the hassle > > of the bootstrap.=C2=A0 Of course, a trojan horse could be in that tarball > > and squirrel itself away ... but then, I'm not supporting Fort Knox, > > either...=C2=A0 that'll save some work ;-) > > What do you refer to by "bootstrap"? >
He is contrasting a stage1 vs stage3 install. Anybody who has been around Gentoo for 15+ years is probably familiar with this but it hasn't been something recommended in a long time or documented in the handbook. I believe it used to be the recommended process. Basically a stage1 is just a tarball of a very minimal toolchain - the very minimum set of packages needed to build everything else and a shell/etc, but not enough to actually boot a system (no ssh, probably no init/openrc, etc). You then use that stage1 to rebuild itself, which becomes a stage2. That is done to clean up any CFLAGS issues associated with whatever built the stage1. Then stage2 is used to essentially do an emerge -e @system which becomes a stage3. The problem is that you end up rebuilding gcc/glibc/python/etc multiple times, and all this time you don't have a bootable system. If for some reason you have to reboot/etc it can be a real pain to resume something like this. This is why it was deprecated - you get the same benefit from just starting with a stage3 and just doing an emerge -e @world, and it means you can do most of your system setup and get your system into a state where it can be rebooted very early, vs having a process where you do some stuff at the start, then do some more a day later, and do a bit more a day later, and so on. You can do an emerge -e @world at anytime really if you want to rebuild everything and other than the load it is pretty transparent to using the system, and if you reboot midway you just do an emerge --resume. You can still find stage1 tarballs, because they're still generated by catalyst when release media is created. The stage1/stage2/stage3 steps are done centrally by the release media team, and then users just download the stage3 tarball. The full process is still used in some more exotic situations, like prefix, or maybe when getting Gentoo running on a new arch. Getting to the trojan horse concern - I guess anything is possible, but you're assuming that somebody would infect the stage3 but not the stage1. They're both generated at the same place and signed using the same keys. If you're concerned about downstream infection a simple gpg check eliminates that risk, and if you're concerned about contamination upstream from signing then you'd need to create your own stage1 by hand from some source you consider clean. -- Rich