Eu fui para distros base Arch atraído pela proposta de montar meu próprio sistema a gosto, mas conforme fui experimentando mais e mais com o sistema, as “paredes” de customização ficavam mais claras. Um exemplo bem simples é o Vim com suporte a copiar e colar: nos repositórios do Arch, não há como ter “apenas” o Vim de terminal com habilidade de copiar e colar do servidor gráfico, ou você escolhe o Vim de terminal (vim), ou você escolhe o pacote do Vim com interface gráfica (gvim – mas eu nunca usei o comando gvim, só o vim de terminal)
Era possível ter isso: tinha um pacote no AUR, apesar de desatualizado, com esse programa. Eu baixei o PKGBUILD, fiz uns remendos, e tinha o Vim como eu queria. Dei o mesmo tratamento para mais e mais coisas (muitas vezes encontrando PKGBUILDs de pessoas com as mesmas reclamações, e utilizando-os). Quando percebi, já estava compilando e recompilando uma boa parte do meu sistema a gosto. Então por que não ir logo de vez para uma distro source-based?
Minha primeira parada foi o KISS Linux, do criador do neofetch. Porém, em muitos aspectos, ela é tão engessada na visão do criador quanto o Arch (porém na direção de um minimalismo extremo), e adaptá-la continuava sendo tedioso. Voltei para a base Arch, que pelo menos me atendia. Confesso que o relato do @RuKsu me levou a dar uma chance para o Gentoo. Já ouvia falar bem das USE flags, e parecia ser exatamente o que eu queria.
Depois de duas semanas usando Gentoo, vão aqui minhas observações.
Atalhos ilegais
Para a instalação do Gentoo não ser (ainda mais) uma perda de tempo, eu criei uma partição vazia de 20GB no meu HD, extraí a Stage 3 para ela, e instalei o Gentoo enquanto tocava minha vida com o Artix (demorando pouco mais de um dia e meio). Isso é inclusive boa parte da experiência Gentoo num computador com uma CPU potente o suficiente: a única coisa que muda é as ventoinhas girando mais que o normal, e consigo fazer uma quantidade boa de multitarefas enquanto o sistema compila (a principal exceção é o Chromium, que realmente tenho que fechar muita coisa para compilar em paz).
Quando o Gentoo mostrou-se viável, removi as pastas da partição do Artix exceto /home e /etc, e passei as pastas do Gentoo via rsync -avH para a partição original usando um LiveCD. É uma técnica que eu já usei bastante para fazer distro hopping. 
Configuração do Kernel
Em uma distro source-based, tem de se fazer o balanço entre um kernel só com o necessário e portanto rapidinho de compilar e um kernel que estivesse preparado para tudo. Tentei colocar o balanço rumo ao primeiro, usando a técnica do make localyesconfig (copiar a configuração do kernel que já está rodando) que o KISS Linux já me ensinara, e acabou que tenho várias instâncias de:
make menuconfig
make modules && make modules_install
no histórico do shell da conta root para compilar e instalar drivers na hora. Esqueci até mesmo dos drivers para pendrives USB. Esse último inclusive me mordeu pois a versão atual do kernel oficial do Gentoo (5.10.61-gentoo) não reconhecia pendrives USB de jeito nenhum, mesmo depois de adicionar o módulo e reiniciar (em vez disso, produzindo um kernel oops). Acabei pegando e compilando um tarball do kernel.org mesmo, e desde então todo o hardware que tenho aqui funciona.
Atualização de software
O Gentoo tem uma abordagem interessante. No repositório oficial, a maioria dos programas tem dois ebuilds: um com uma versão antiga e testada, e outro, marcado como em testes e que não é instalado por padrão (e permanece assim por 2-4 semanas), com a versão mais recente. Quem quer sempre as últimas novidades, edita a variável ACCEPT_KEYWORDS para incluir ~amd64 no /etc/portage/make.conf, ou adiciona categoria/pacote ~amd64 no final de /etc/portage/package.accept_keywords.
É dois em um, Arch e Manjaro!
Porém, alguns pacotes me passaram a impressão que o repositório do Gentoo é maior do que os mantenedores conseguem lidar. Dois programas que eu uso bastante (snownews e s6) tinham versões bastante desatualizadas (por mais de um ano), por exemplo.
Sistema de empacotamento
USE Flags (e o /etc/portage/make.conf em geral)
Esse é sem dúvida o grande trunfo do Gentoo. USE flags permitem ajustar com quais recursos e dependências todo o software do sistema é compilado, tornando o código-fonte dos programas o único limite para a customização. Retomando o exemplo do começo, foi só compilar o vim com USE="X" para tê-lo exatamente como queria. Os parâmetros de compilação são transformados em USE flags para o sistema ficar amigável de se customizar.
Há outras variáveis que igualmente permitem enxugar os pacotes do sistema, como VIDEO_CARDS (compilar apenas drivers de vídeo relevantes para seu sistema). Aqui, por exemplo, eu tenho uma das placas da AMD que aceitam tanto o driver antigo radeon quanto o novo amdgpu. Como eu nunca quis usar o radeon (já que ele não tem Vulkan), simplesmente não tenho radeon na minha lista de VIDEO_CARDS. O meu sistema então carrega o amdgpu direto sem nem precisar do parâmetro de linha de comando no GRUB.
Mesmo entre distros source-based isso é um ponto para o Gentoo, pois há muitas em que os parâmetros de compilação são bastante engessados no equivalente do PKGBUILD, e o trabalho de modificar o sistema é basicamente o mesmo de uma distro binária. Já dei o exemplo do KISS Linux, mas isso se aplica a muitas outras que eu pesquisei.
Os espinhos das USE flags são até que poucos para o poder que elas destravam (por exemplo, a dependência cíclica entre os pacotes Freetype e Harfbuzz, que são infames por interromper muitas instalações de Gentoo).
É possível também personalizar as USE flags pacote-por-pacote com /etc/portage/package.use.
Quem quiser investigar o que há disponível em cada pacote pode usar: equery uses PACOTE.
Overlays
Não há um equivalente de um AUR centralizado no Gentoo. Em vez disso, a obtenção de software fora do repositório (ou mesmo de scripts de compilação alternativos para software dentro do repositório) ocorre por meio de overlays, que são repositórios que se “sobrepõem” ao da distro. Na tradição Gentoo, o repositório da distro vem por padrão com o mínimo de prioridade.
Para entender um overlay, vale citar a estrutura do repositório do Gentoo:
repositorio
└categoria
└programa
└programa-versao.ebuild (script de compilação)
Overlays têm essa mesma estrutura, adicionando novos programas ou substituindo os que vêm na distribuição.
Há duas vantagens no esquema de overlays:
- Brincar com pacotes centrais do sistema sem atualizações arruinarem tudo não é difícil, basta criar um overlay os substituindo. Há quem use Gentoo com
runitcomo esquema de inicialização mesmo não sendo uma opção oficial. - A procedência dos pacotes num overlay é mais fácil de garantir. Na wiki, inclusive, há uma lista de overlays confiáveis, ferramentas de busca nos mesmos e um script para facilitar sua adição e remoção (
eselect-repository).
A grande desvantagem, é, bem, caso você não ache o pacote que busca nos confiáveis, é difícil navegar no mar de overlays de usuários “comuns” do Gentoo até achar o que você quer – quase sempre compensa mais você fazer seu próprio.
Ebuilds
O ebuild é o equivalente Gentoo do PKGBUILD do Arch.
O ebuild do Gentoo é bem mais complexo. Além de compreender as instruções de compilação do site oficial e saber o básico da linha de comando do Linux, é também necessário conhecimentos bem específicos de ebuilds, como classes (git-r3, meson, etc.), comandos específicos do mesmo (emake, eninja, dodir, insinto, etc.), as diferenças entre EAPIs (versões do formato ebuild)… Me pareceu um processo bem menos direto que os equivalentes em outras distribuições.
Portage
Deixei para falar do Portage por último porque ele é um programa bastante competente, e é graças a ele que o Gentoo é surpreendentemente fácil de usar para o tanto de portas de customização que ele abre. Os destaques dele, para mim:
- A resolução de dependências dele leva em conta as USE flags que você escolheu, e alerta caso sejam necessárias mudanças. Há até parâmetros como o
autounmask-writepara fazer essas mudanças automaticamente. Nenhuma compilação aqui falhou por falta de dependências com ele. - Facilita bastante a aplicação de patches (aqui mesmo, apliquei uma correção de bug em um programa com esse recurso, sem nem precisar tocar no ebuild).
- A possibilidade de mascarar pacotes e garantir que eles nunca vão ser instalados (preferindo uma alternativa em um overlay, por exemplo), semelhante aos “tabus” do Zypper.
Conclusões
Gentoo definitivamente não é para todo mundo. Eu ecoo as palavras do RuKsu no final dele, exige paciência, vontade de aprender, estudar, treinar e, especialmente no começo, um pouco de tempo livre. Talvez os benefícios nem sejam aparentes ou relevantes, dependendo do seu uso.
Montando o meu Gentoo, entendi porque é chamado de meta-distribuição: dá para chegar a muitos resultados diferentes com ele, e duvido que as instalações de Gentoo de mim, do RuKsu e do Deleterium sejam iguais uma as outras, tanto “em cima” quanto “embaixo” do capô. Deixando o Python e o Bash quietos para o Portage funcionar, praticamente todo o resto é jogo limpo, e o gerenciador de pacotes faz o possível para isso ser conveniente. Para quem valoriza escolha e experimentação, o Gentoo é bom playground.
(Conseguiu até tirar minha atenção de assistir o VT da P3 e Qualify da Formula 1 e olha que é muito difícil isso hein… 
)
mais vezes eu clicaria (poder eu posso mais não vai adicionar mais que 1 
). Excelente relato e opiniões sobre a convivência com o Gentoo, Capezotte! Agregou muito mais aos meus poucos conhecimentos nesta distro Gentoo que já é minha favorita de longe! Muito obrigado Capezotte!
apaixonado pelo Gentoo.
, me colocou numa “luta” para oconfigurar o ~amd64 direto no make.conf… Preciso estudar mais o porquê de o Portage estar recusando…) Tenho muito que aprender sobre o Gentoo.
E para piorar o erro intergaláctico eu resolvi atravessar o tecido dos universos para ver oque tinha após o final e deletei a instalação começando tudo denovo, invez de tentar recuperar a imagem. 
.
).