# Jornal dos Pindoramas #1: O que foi feito pelo Copacabana nos últimos 4 anos?

Note for non-lusophones (or people that definitively can not read Portuguese even per mutual inteligibility): Since this is the first edition of what can be called a “devlog”/”devjournal”, it is sort of reserved for people closer to the core of the Copacabana project, a group composed per a considerable majority of lusophones. If you can not read Portuguese or feel more confortable reading in your first language, a machine translator will work just fine. I intend to write the next edition also in English.

Primeiramente, salve São Jorge!
Segundamente, sim, 4 anos. É o tempo de um mandato à presidência do Brasil (e dos E.U.A.), e é o tempo que o Copacabana tem de existência, desde a concepção da ideia em 2021, até o primeiro lançamento entre meados de 2022 e o começo de 2023, passando por uma mudança de compilador e a automatização do processo de montagem em 2024 até agora. Percebi que, ao invés de recomendar que leiam a lista de commits e/ou que assinem a lista de observadores do repositório com o que é efetivamente o arcabouço da distribuição, seria melhor escrever resumidamente sobre o que foi feito até agora.
Por uma questão de simplicidade, é melhor começarmos por hoje: sim, boa parte já foi feita — por mais que algumas coisas precisem de certa revisão, como o leiaute dos scripts que determinam como um pacote deve ser compilado para o sistema e, por consequência, as funções que interpretam-no —, apenas faltando finalizar a lista de pacotes, o que, por mais que pareça muita coisa, é facilitado graças ao manual escrito em 2022 para a versão 0.4 e que ainda se aplica com pouca adaptação. Não há muito uma razão para se entrar em detalhes de cada mudança feita individualmente no sistema de montagem durante os anos de 2023 e 2024, mas posso citar algumas: um parser de INI feito do zero a fim de se poder usar um bom formato para os arquivos de configuração, novas funções para exibir o registro das atividades em tela, funções para manipular a variável PATH, suporte ao uso do aria2 no script que transfere os arquivos compactados com código-fonte, vulgo cmd/download_sources.ksh, etc, a lista vai longe.
Além da parte principal do projeto, do arcabouço da distribuição, também existem os projetos associados, que vão desde o projeto mussel, passando pelo Heirloom “Esquema Novo”, parte integral da userspace do sistema, até coisas que parecem menores, mas que tomam um tempo considerável de, no mínimo, dois dias para alguma mudança relevante, como o gerenciador de pacotes, que depende de algumas funções da libcmon ainda não implementadas, e implementações alternativas de programas requisitados — como, por exemplo, o port do programa patch do OpenBSD — o que, sim, apesar de parecer dispensável, sempre foi um objetivo não apenas do Copacabana, mas essencialmente de todo o projeto Pindorama.
É difícil encontrar contribuidores para esses projetos pois, quando não são hobbistas demais ao ponto de ainda não conseguirem ajudar por falta de conhecimento, estão contratados, ou estão com um burnout para lá de conveniente — ou, até mesmo, as duas anteriores —, então torna-se um trabalho praticamente de uma pessoa só; o que felizmente não é o caso do Heirloom pois, por esse ser um projeto mais geral, trouxe maior interesse externo e, consequentemente, novos contribuidores, e que também não é o caso da mussel pois, como pode-se ver, é mais um trabalho de cooperação entre o projeto Pindorama e o glaucus do que algo que depende inteiramente de nós.