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 D0AE41382C5 for ; Sat, 20 Jan 2018 21:48:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 04CCFE0884; Sat, 20 Jan 2018 21:48:44 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 99FD0E0805 for ; Sat, 20 Jan 2018 21:48:42 +0000 (UTC) Received: from [IPv6:2600:8802:605:7900:2e33:7aff:fef2:3005] (unknown [IPv6:2600:8802:605:7900:2e33:7aff:fef2:3005]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 781B2335C31; Sat, 20 Jan 2018 21:48:41 +0000 (UTC) Subject: Re: [gentoo-dev] Re: Managing updates on many identical Gentoo systems To: gentoo-dev@lists.gentoo.org, "Anthony G. Basile" References: <2686de8e-334c-084b-4828-6109b10dd536@gentoo.org> From: Zac Medico Message-ID: <3cbcbbad-c0eb-f2c5-5fcd-9402f2d4ea29@gentoo.org> Date: Sat, 20 Jan 2018 13:48:37 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KXI7dON1DSHV2Nee1i2POjlSuft90z7Md" X-Archives-Salt: 1d51ad1d-edb5-4ebb-af5a-5efbd66bece8 X-Archives-Hash: c8b5c2d7f35e1a966dd40f9c95411d9d This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KXI7dON1DSHV2Nee1i2POjlSuft90z7Md Content-Type: multipart/mixed; boundary="DUVNann5dYvMy9u90z09bcqXDQojPzIrX"; protected-headers="v1" From: Zac Medico To: gentoo-dev@lists.gentoo.org, "Anthony G. Basile" Message-ID: <3cbcbbad-c0eb-f2c5-5fcd-9402f2d4ea29@gentoo.org> Subject: Re: [gentoo-dev] Re: Managing updates on many identical Gentoo systems References: <2686de8e-334c-084b-4828-6109b10dd536@gentoo.org> In-Reply-To: --DUVNann5dYvMy9u90z09bcqXDQojPzIrX Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 01/20/2018 07:34 AM, Anthony G. Basile wrote: > On 1/19/18 10:03 AM, Anthony G. Basile wrote: >> >> Zac pretty much nailed the requirements in bug #644990. You should no= t >> need the portage tree at all, neither locally nor via any network >> filesystem. He mentions there that it is currently possible via "a >> dummy profile", but I'm not sure what he means by that yet or how to s= et >> one up. I'll read his bug #640318 and try to figure it out. >> >> Thanks guys, I'm glad people at least recognized the usefulness of suc= h >> a possibility. >> >=20 > Okay, I have a workable solution to my question. I was able to get > binhost working with a portage tree containing ONLY /profiles and > /eclass. That's 12MB and 2.8MB in size, respectively, and I can > probably dump a bunch of the unused profile directories slimming that > down. With just those two directories in PORTDIR, emerge -K pulls down= > the update packages from BINHOST and installs them. >=20 > @zac any comments about this approach? Is it likely to break? It's desirable to rely exclusively on the BINHOST as a single source of truth, since otherwise you have to keep multiple data sources in consistent states. You should not need the eclasses, since portage uses the eclass code from environment.bz2 that is embedded in each binary package. Using /profiles can cause problems because things like package.mask and package.keywords have to be consistent with the BINHOST. For the above reasons, I use a dummy profile. I also sync /profiles/updates so that emerge can apply package moves, but I intend to eliminate that as part of bug #644990 since keeping /profiles/updates consistent with the binhost is not practical. --=20 Thanks, Zac --DUVNann5dYvMy9u90z09bcqXDQojPzIrX-- --KXI7dON1DSHV2Nee1i2POjlSuft90z7Md Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHEEARECADEWIQSG5RNTeMgVEruefzL96O+FrlcZowUCWmO5NRMcem1lZGljb0Bn ZW50b28ub3JnAAoJEP3o74WuVxmjCikAoMLmZITuryoD1v7YKur8V+KnfhucAJ9L SqylDyQuVzI2YUaxGkMrpMGL1g== =vY1U -----END PGP SIGNATURE----- --KXI7dON1DSHV2Nee1i2POjlSuft90z7Md--