How do you prefer organizing your Portage config?

[spork_kitty]

I'm reaching a point where I need to manage Portage config for two different machines, on different arches, and being able to store backups would be nice, too. One will (eventually) be a distcc/crossdev machine for the other one as a binhost.

The obvious solution is to put it into version control and divide sets into logical groups. I have a few ideas on what I think might work:

• branches as hosts
  
• tags as 'checkpoints' or known-good configs
  
• Regular /etc/portage structure otherwise
  

How do you guys manage your Portage config?

One thing I'm curious about is how I'll tie modifying the repo to /etc/portage. Would a symlink be enough?

[erm67]

I use ACCEPT_KEYWORDS for the stable arch in make.conf and add the main package to package.accept_keywords without specifying a version, instead I specify a version for dependent packages (mostly what emerge suggests i.e. --autounmask-write). Of course after a while (years) the file grows too big and filled with useless entries, also other files like package.use becomes old since most of the times I don't pay attention if there are changes in the use flags.

I use the same config on amd64 and arm64 since I also use accept_keywords=~amd64 on arm64 because since the birth of gentoo packages on secondary arch were never tested and keyworded properly and almost certainly they never will. Beside that I natively emerge while devs crosscompile on arm so some packages like haskel or elixir will never work for them while work fine for me just like on ~amd64. Basically arm64 keywording is totally useless for people natively emerging, the keyword should named ~crossarm64 but that would be even more useless since there are already too many keyword/package combination for them to test, one more keyword would just exacerbate a problem that affects gentoo since its inception. Not to mention use flags ....
A solution would be simplifying the keyword system and use blacklisting on secondary archs development keywords instead of whitelisting that can be used for the stable.

ACCEPT_KEYWORDS=~*

don't work well yet unfortunately since portage autounmask feature ignores it.
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia

My fediverse account: @erm67@erm67.dynu.net

[Dr.Willy]

That topic came up a while ago. IIRC pjp had the rather interesting idea of using a custom profile. Not sure what came of it tho.