Após um ano de desenvolvimento, foi lançado o gerenciador de pacotes RPM 4.20.0. O projeto RPM4 é desenvolvido pela Red Hat e é utilizado em distribuições como RHEL, Fedora, SUSE, openSUSE, ALT Linux, OpenMandriva, Mageia, PCLinuxOS e Tizen. O código do projeto é distribuído sob as licenças GPLv2 e LGPLv2.
No próximo ano, espera-se a publicação de uma versão significativa do RPM 6, que utilizará um novo formato de arquivo, permitindo, ao contrário do formato cpio atualmente em uso, criar pacotes maiores que 4 GB (superar esse limite é importante, pois o pacote SRC do Chromium está próximo do limite, com 3,7 GB de tamanho). Na nova versão, também se pretende permitir o uso da linguagem C++ para desenvolver RPM. Esta nova versão importante será comemorativa — no dia 27 de novembro de 2025, o projeto completará 30 anos desde o primeiro commit no RPM. As versões 5.x do RPM serão puladas para evitar sobreposições com o projeto RPM5, que não está diretamente relacionado ao RPM da Red Hat, sendo desenvolvido por uma equipe independente de desenvolvedores e não recebe atualizações desde 2016.
As melhorias mais notáveis no RPM 4.20:
- Foi incluída uma nova ferramenta, rpm2archive, que substitui a ferramenta rpm2cpio e facilitará a transição para o novo formato de pacotes que não usa cpio. Diferentemente do rpm2cpio, a nova ferramenta converte o arquivo RPM não em um arquivo cpio, mas em um arquivo no formato tar, comprimido com gzip. A antiga ferramenta rpm2cpio foi substituída por um link simbólico para rpm2archive.
- Foi proposta uma sistema de construção declarativa, que se baseia no uso da nova diretiva "BuildSystem", através da qual pode ser definida a sistema de construção utilizada na formação do pacote. O código-fonte é automaticamente preparado, compilado e instalado de acordo com o sistema de construção especificado, sem a necessidade de definir separadamente no arquivo SPEC os scripts de preparação, construção e instalação nos blocos "%prep", "%build" e "%install". No RPM, os sistemas de construção suportados são definidos na forma de coleções de macros.
A ideia principal é que o formato declarativo de configuração permitirá que os desenvolvedores de distribuições criem macros separadas para processos de construção típicos, evitando a definição de cenários repetitivos em cada pacote. Por exemplo, em vez de definir sequências para executar os comandos configure e make para programas que usam Autotools, agora é suficiente indicar "BuildSystem: autotools" e evitar seções como "%prep", "%build" e "%install". Atualmente, macros semelhantes foram preparadas para Autotools e CMake. Quando necessário implementar comportamentos não padrão, os mantenedores de pacotes têm a opção de adicionar suas próprias macros para redefinir diferentes etapas do processo de formação do pacote.
- Foi adicionada a funcionalidade de anexar seções adicionais com comandos de preparação, construção, instalação, configuração, limpeza e verificação, que complementam as seções básicas %prep, %conf, %build, %install, %check e %clean. Para executar um script adicional antes da execução do código da seção básica, foi proposta a opção "-p", enquanto após a seção básica, a opção "-a". Essas substituições podem ser úteis para ajustes pontuais no comportamento ao usar o modo de construção declarativa descrito acima.
- Foi permitido incluir diretivas e seções em partes dinâmicas dos arquivos SPEC que não afetam o processo de construção.
- Foi adicionado o macro %builddir e implementada a capacidade gerenciada pelo RPM de vincular diretórios de construção personalizados a pacotes individuais.
- Um novo protocolo "multi-file" foi proposto, que acelera significativamente a geração de dependências.
- O comando rpm recebeu a opção "—json" para a saída dos resultados das consultas no formato JSON.
- Foi adicionado o plugin rpm-plugin-unshare, que proporciona isolamento dos scripts executados nas seções de construção, utilizando namespaces no Linux. Por exemplo, o plugin permite proibir o acesso à rede e limitar o acesso ao sistema de arquivos, além de utilizar diretórios privados separados /tmp e /home para proteção em caso de manipulação insegura de arquivos temporários durante a construção dos pacotes.
- Foi proposto um API pública para o desenvolvimento de plugins, que manterá a compatibilidade entre lançamentos. Anteriormente, a API para plugins era destinada apenas ao uso interno e podia mudar de um lançamento para outro.
- As opções "—list" e "—delete" foram adicionadas ao comando rpmkeys.
- A equipe do rpmsign adicionou suporte à criação de assinaturas digitais para pacotes, utilizando chaves ECDSA.
- Melhorado o suporte para compilações repetíveis. Adicionado o macro "%build_mtime_policy", permitindo gerenciar o conteúdo das etiquetas adicionadas durante a compilação, com o valor clamp_to_source_date_epoch para utilizar uma etiqueta fixa ou clamp_to_buildtime para indicar o tempo real de compilação.
- Em arquivos sysusers.d, agora é permitido adicionar linhas para definir membros do grupo.
- Fornecido suporte correto e independente de distribuições para arquivos debuginfo.
- O sintaxe obsoleta dos macros %patchN (sem espaço antes de N) foi declarada como obsoleta, e seu uso agora resultará em um erro (use "%patch N" ou "%patch -P N", onde N é o número do patch).
- Parser OpenPGP obsoleto removido.
- Os geradores de dependências para Perl e Python ABI foram movidos para repositórios separados.
Fonte: opennet.ru
