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

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Re: Managing updates on many identical Gentoo systems
From:       Zac Medico <zmedico () gentoo ! org>
Date:       2018-01-20 21:48:37
Message-ID: 3cbcbbad-c0eb-f2c5-5fcd-9402f2d4ea29 () gentoo ! org
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


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 not
>> 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 set
>> 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 such
>> a possibility.
>>
> 
> 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.
> 
> @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.
-- 
Thanks,
Zac


["signature.asc" (application/pgp-signature)]

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