Skip to content

ARCHITECTURE.md

Latest commit

 

History

History
87 lines (71 loc) · 4.56 KB

ARCHITECTURE.md

File metadata and controls

87 lines (71 loc) · 4.56 KB
Raw

Arquitetura

Camadas e ownership

  1. ghcr.io/ublue-os/bluefin:stable fornece Fedora, bootc, GNOME, identidade, common, kernel, hardware, energia, TuneD/PPD, thermald e ZRAM.
  2. A camada local adiciona apenas ferramentas de segurança, produtividade, Podman/Quadlet, Distrobox, QEMU/KVM local, libvirt modular, VS Code, Niri opcional, jutsu e documentação.
  3. flatpak-preinstall.service, herdado do Bluefin, consome as declarações nativa e local em /usr/share/flatpak/preinstall.d no primeiro boot.

O Finpilot é referência para contexto separado, scripts numerados, modo estrito, limpeza e validações. Seus estágios common e brew não são copiados: ambos já foram compostos pelo Bluefin pai. A camada Akatsuki preserva as declarações Flatpak herdadas, incluindo Bazaar, e acrescenta sua lista de quatro aplicativos.

O projeto aplica somente wallpaper, GDM e ícones Akatsuki. Plymouth e Niri permanecem sem customização local. O projeto não substitui os-release, hostname nem a identidade técnica Bluefin. Também não instala política própria de energia, não mascara TuneD/PPD, não fornece ZRAM própria e não define sysctls vm.*. Overrides locais anteriores que desligavam economia de Wi-Fi e áudio foram removidos. O perfil Lean retira impressão, modem, Avahi, Thunderbolt userspace, smart card, ZFS, câmera virtual, idiomas CJK e backends remotos de VM. geoclue2 e flite permanecem somente por dependência rígida do GNOME/WebKit; o serviço GeoClue é mascarado. O módulo Dracut pcsc é retirado da configuração herdada, preservando FIDO2/TPM/PKCS#11 e futuras atualizações de kernel sem pcsc-lite.

Virtualização local preserva KVM, QCOW2, VirtIO, SPICE, PipeWire, NAT, virtiofsd, OVMF e TPM virtual. Os metapacotes generalistas qemu-kvm e libvirt-daemon-kvm são substituídos por componentes explícitos.

O inventário da imagem anterior confirmou tuned, tuned-ppd, thermald, zram-generator, switcheroo-control e systemd-oomd. Após cada rebuild, as invariantes confirmam novamente pacotes, units e arquivos upstream; hardware e temperatura ainda exigem validação na máquina real.

Supply chain

Bluefin usa o canal móvel stable. O build deve usar --pull=always; o digest resolvido pertence ao registro de cada build e deve ser guardado para auditoria e rollback. O projeto não executa upgrade parcial sobre esse digest. Pacotes adicionados localmente vêm do Fedora e têm vendor validado, exceto o VS Code oficial. Seu script valida a fingerprint Microsoft BC52 8686 B50D 79E3 39D3 721C EB3E 94AD BE12 29CF, confirma o vendor e remove o repositório transitório.

A integração Homebrew existente no Bluefin não é usada para instalar dependências obrigatórias deste perfil. Seu payload permanece herdado, mas bootstrap, preinstall e timers são mascarados quando presentes. Toolchains e serviços de projeto devem preferir containers. O banner opcional umotd continua removido para reduzir ruído e superfície de dependências.

Atualização e persistência

O sistema é atualizado como imagem por bootc. Timers bootc/rpm-ostree, uupd.timer e o gatilho uupd em AC são mascarados; check, aplicação e reboot são explícitos. /etc e /var seguem a semântica bootc; HOME, Flatpaks, Distroboxes e volumes possuem ciclos separados. Machine-id, random seed, hostname local e host keys não pertencem à camada.

ISO de instalação

A ISO interativa é um artefato derivado, não uma segunda imagem de sistema. Titanoboa extrai a imagem OCI publicada, adiciona somente o ambiente live e o Anaconda, incorpora o mesmo payload em containers-storage, gera o initramfs live e monta a mídia UEFI/GRUB sobre SquashFS. O hook em iso/configure-anaconda.sh configura Btrfs, copia os Flatpaks para o deployment e registra no sistema instalado a mesma referência GHCR usada no build.

O namespace do payload é fixo em ghcr.io/lnx89f/akatsuki-linux; o helper resolve a tag antes da composição e fornece o payload ao Titanoboa por digest. Metadados image-info.json herdados do Bluefin não são usados para escolher o sistema a instalar. O workflow de ISO é exclusivamente manual e produz apenas um artefato de teste. Build da imagem, assinatura do payload, build da ISO, validação e promoção são decisões separadas.

Riscos de composição

O conteúdo de bluefin:stable, nomes de pacotes e units pode mudar. O build deve falhar em vez de esconder incompatibilidades. Não copie novamente projectbluefin/common sobre a imagem Bluefin e não replique scripts internos do upstream; isso criaria duas fontes de verdade.