On 01/18/2018 08:13 AM, Alec Warner wrote: > On Thu, Jan 18, 2018 at 6:46 AM, Anthony G. Basile <bluen...@gentoo.org > <mailto:bluen...@gentoo.org>> wrote: > > Hi everyone, > > I'm trying to design an update system for many identical Gentoo systems. > Using a binhost is obvious, but there are still problems with this > approach. > > Unless there's some magic I don't know about (and this is why I'm > sending this email) each machine still needs to have the portage tree > installed locally (1.5 GB) or somehow mounted by a network filesystem > (which is not practical if the machines are not on a local network). > > > +Zac > > I don't believe this is true; with the correct binhost configuration > portage should: > > 1) Contact the binhost to get a dump of packages available on it. > 2) Use that dump to create a 'virtual portage tree' (bindb). > 3) Use the bindb for package discovery (is foo available) and dependency > calculation.
It's already possible if you use PORTAGE_BINHOST and create a dummy profile to satisfy portage. I've filed this bug to create a convenient option for this: https://bugs.gentoo.org/644990 > > Furthermore, each machine would have to run emerge locally to do the > calculation of what packages need updating. > > > The good news is that with a bindb; the package tree itself is much > smaller. ::gentoo is 23000 packages. > But you bindb is only as large as you build binpkgs for and publish > them. So say stage3 + some other stuff. > Around 500 packages perhaps. Doing the calculation on the client side is fine, since binary package calculations are much simpler than source-based ebuild calculations. -- Thanks, Zac
