From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 28D9D1382C5 for ; Thu, 21 May 2020 12:34:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C4DECE095D; Thu, 21 May 2020 12:34:29 +0000 (UTC) Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6FB1BE0952 for ; Thu, 21 May 2020 12:34:29 +0000 (UTC) Received: by mail-ed1-f51.google.com with SMTP id s19so6518276edt.12 for ; Thu, 21 May 2020 05:34:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=c+PPrML7ynZJCi7W+uQyKDc9+JpPDWlTpDRwq6i1mN0=; b=XbH4n0NvgZsw30CaVMBjA95y3c1loatCKKeV2Zb7JtonjW4f3hXfprc18Sv5UzGigv d425LpNrj3GLuscO6/ZGyWtpKsiqEC5oxle5XGMWSe4yMgLobsovFmat2/mf2490Lwwc eKFVbuOGwTGWcIN/HQRrqJMijKzIgx1j0AiYzjvF/fsMXymaToh0ZpTytbOUcokT0/9c MI6cfLNGMuRc7d3ETVjMRSUPbE2m61Pnhbuum7hExp3Uv1+GN8Vunj4eXghvODC3mvVp 56LDV7JcHb8DBL7hSqMeDjuEalvDU/gsaVeqwwA8A52AzC1lWRx2d7rfd4ANNLVMNHco bxQg== X-Gm-Message-State: AOAM5321qtuXZZgWTBhGvU4E0oaj9AECYJwiuIsELL74qs6CrLCtwRvK YuDoLYrJ6+AK8H99Z0RiOwnvnNo6Ub7pRNCWIkIY1Ys2aNc= X-Google-Smtp-Source: ABdhPJx1dHQeqX9nwFcGAz0Ic/VHqqCAZjo4B6B++IrWODFW1aCiwQdshR7HfSAFavDORlZPl2hF5XRNdlb3l04AjJM= X-Received: by 2002:aa7:d495:: with SMTP id b21mr7336963edr.16.1590064464652; Thu, 21 May 2020 05:34:24 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <58627e0c-0ff6-7280-7506-63a43abfd988@web.de> <20200520165928.cziltdysjc3pbzg3@ad-gentoo-main> <9b443081-d522-31f0-2d7c-061a37f5ea35@gmail.com> <4d06e249-4ae7-048d-7478-17ad62e942ec@web.de> <2d4e5dc7-b658-5826-5f4b-fc73629c837b@web.de> <20200521084621.B38EDE08AD@pigeon.gentoo.org> In-Reply-To: <20200521084621.B38EDE08AD@pigeon.gentoo.org> From: Rich Freeman Date: Thu, 21 May 2020 08:34:13 -0400 Message-ID: Subject: Re: [gentoo-user] slot conflict for the same package: how to add a USE flag? To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 64730483-ace6-4453-a3ce-83d7e05ad62a X-Archives-Hash: 8ace45dea9ca32a293de0901439d1dd5 On Thu, May 21, 2020 at 4:46 AM Thomas Mueller 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