Se você desenvolve no Fedora e, em algum momento, já sofreu tentando “congelar” um ambiente para o time inteiro usar igualzinho (mesmas libs, mesmas versões, mesma dor de cabeça), aqui vai uma novidade que tem cara de alívio: o FESCo (Fedora Engineering Steering Committee) aprovou a proposta para empacotar o Nix nos repositórios oficiais do Fedora 44, previsto para o primeiro semestre de 2026.
A ideia é simples de entender, mesmo que a tecnologia por trás seja bem poderosa: em vez de você depender só do mundo DNF/RPM para tudo, o Fedora vai passar a oferecer uma “oficina portátil” extra para projetos específicos, sem mexer na estrutura da casa.
O que é o Nix e por que tanta gente gosta dele
O Nix é um gerenciador de pacotes funcional e multiplataforma, feito com uma obsessão saudável por reprodutibilidade. Em termos práticos, ele tenta garantir que “se funciona na minha máquina” também funcione na sua, no CI, no servidor, e daqui a três meses, quando alguém resolver atualizar metade do mundo sem avisar.
O segredo está no jeito como ele descreve pacotes e ambientes de forma declarativa (as famosas derivations) e, cada vez mais, via flakes, que viraram o caminho moderno para definir ambientes de desenvolvimento repetíveis. Some isso ao ecossistema nixpkgs com mais de 100 mil pacotes e você tem um universo paralelo de dependências, versões e ferramentas, pronto para ser usado sem contaminar o sistema base.
Nix nos repositórios oficiais
A notícia aqui não é “Fedora vai virar NixOS”. Longe disso. O ponto é: no Fedora 44, instalar Nix deve virar um dnf install nix da vida, em vez de depender de gambiarras, scripts externos ou repositórios alternativos. A proposta também mira versões do Nix 2.31 ou superiores, alinhando o empacotamento com o que a comunidade já usa hoje.
Pense no DNF/RPM como a caixa de ferramentas padrão do Fedora, tudo organizado para o sistema funcionar redondo. O Nix é aquela bancada dobrável que você abre quando vai montar um projeto específico: ela traz ferramentas próprias, regras próprias e um estoque gigante de peças, sem sair furando parede nem mexendo na fiação da casa.
A polêmica do diretório /nix (e por que houve “exceção”)
Aqui está o detalhe mais técnico, e o mais revelador: o Fedora normalmente evita que pacotes criem diretórios diretamente na raiz do sistema (/). Só que o Nix tem um “endereço” clássico e importante: /nix.
Para o Nix funcionar como foi desenhado (incluindo cache binário, compatibilidade com o ecossistema e o modelo de store), ele precisa desse caminho padrão. Por isso, o FESCo aprovou uma exceção nas regras de empacotamento para permitir o uso do /nix em tempo de execução. No empacotamento proposto, esse diretório é definido via tmpfiles.d e pode até virar um subvolume Btrfs, se você quiser organizar melhor a casa.
O ponto que o Fedora faz questão de frisar é importante: /nix não será puxado pelo sistema base nem vira parte do “esqueleto” do Fedora. Ele entra como algo opcional, voltado a quem conscientemente decidiu usar Nix.
Escopo, limites e o aviso que você não deve ignorar
O Nix será uma ferramenta opcional para desenvolvedores. Ele não substitui DNF/RPM, não muda o modelo de suporte do Fedora e, principalmente, os pacotes instalados “dentro do Nix” não passam pelo QA do Fedora nem têm suporte oficial da distro. A comparação usada na própria proposta é bem honesta: é como usar pip para instalar coisas fora do repositório da distribuição, a responsabilidade é sua.
Também tem nuances práticas: em sistemas baseados em rpm-ostree (como Silverblue/Kinoite), o /nix na raiz é incompatível, então o caminho costuma ser usar Nix dentro de container (toolbox) ou adotar uma instalação rootless. E vale o lembrete amigo: Nix pode comer bastante disco, então limpeza periódica com nix-collect-garbage vira parte do ritual.
