DNF5: Gerenciador de Pacotes

DNF4 para DNF5

Já vimos nessas notas o funcionamento do DNF, gerenciador de pacotes de software no linux. Nessa ocasião o comando dnf se referia (era um aliás) para dnf4. O Fedora mudou do DNF4 para o DNF5 devido à necessidade de atualizar e melhorar o gerenciador de pacotes do sistema operacional. O DNF5 foi construído pelo esforço coletivo das equipes do Fedora e do Red Hat, e traz várias vantagens em relação à versão anterior, incluindo melhor desempenho, maior estabilidade, correções de bugs e melhorias na interface do usuário. Além disso, o DNF5 oferece suporte a novas funcionalidades e melhor integração com outros componentes do sistema operacional. O DNF5 está instalado no Fedora desde a versão 38, não sendo o gerenciador de pacotes padrão, por default. No Fedora 41 ele é instalado como padrão, e recebe o álias dnf. A versão anterior está ainda disponível, bastando digitar dnf4 na linha de comando. Uma página da documentação descreve as alterações entre dnf4 para dnf5, em Changes between DNF4 and DNF5.

O que é um gerenciador de pacotes?

Um gerenciador de pacotes é um conjunto de aplicativos usados para automatizar o processo de instalação, atualização, configuração e remoção de programas de computador de uma maneira consistente. Ele manipula pacotes, que são distribuições de software e dados, contendo metadados como o nome do software, descrição de propósito, versão, fornecedor, checksum e uma lista de dependências necessárias. Na instalação, os metadados são armazenados em um banco de dados local. Gerenciadores de pacotes usam esse banco de dados de dependências para evitar incompatibilidades de software e pré-requisitos ausentes. Eles trabalham em conjunto com os repositórios de software, algumas vezes acessados pelas lojas de aplicativos. Diversas distribuições Linus usam DNF (ou YUM), entre elas: RedHat Enterprise Linux, Fedora, CentOS, Oracle Enterprise Linux, SUSE, OpenSUSE, Mageia e Turbolinux.

Nessas notas descreveremos o aplicativo DNF5 sem fazer alusão alusão ao artigo anterior, para que ele possa ser lido independentemente.

Usamos aqui as seguintes convenções:
# linhas de comentários
$ linhas de código (input)
➡ linhas de saída (output)

O que é RPM?

O RPM Package Manager (RPM) é um sistema de gerenciamento de pacotes de código aberto. Os arquivos que ele empacota recebem a extensão .rpm. O gerente RPM foi criado para uso no Red Hat Linux, mas agora é usado em muitas distribuições Linux, como PCLinuxOS, Fedora Linux, AlmaLinux, CentOS, openSUSE, OpenMandriva e Oracle Linux.

Um pacote RPM pode conter um número variado de arquivos. A maioria deles são “RPMs binários” (ou BRPMs), que contém a versão já compilada de algum software. Também existem “RPMs de origem” (ou SRPMs) que trazem o código-fonte usado para construir um pacote binário. Nesse caso eles têm uma tag no cabeçalho do arquivo que os marca como SRPM e faz com que esses arquivos sejam extraídos para /usr/src na instalação.

Repositórios: RPMs são frequentemente coletados em um ou mais repositórios na internet, chamados repositórios. Alguns sites replicam esses repositórios, nos espelhos locais (ou mirrors). Aplicativos destinados a faciltar o uso desses arquivos, gerenciando instalações, dependências e conflitos são os front ends. Alguns exemplos são: YUM (a base para o dnf); DNF; up2date; Zypper, urpmi, apt-rpm, uma adaptação para usar pacotes rpm no Debian, entre outros.

Banco de dados de instalação local: o gerenciador de pacotes usa uma banco de dados (rpmdb), armazenado em /var/lib/rpm. Diversos gerenciadores podem ser usados, como o SQLite ou Berkeley DB, contendo todas as meta informações dos pacotes instalados. É possível identificar qual o gerenciador está sendo usado com o comando rpm --showrc. Esse banco de dados indexa a informção para acelerar as consultas, e mantém o controle de todos os arquivos alterados e criados pelo usuário, permitindo a reversão das alterações e remoção de pacotes. Em caso de corrupção desse banco de dados de índice, eles podem ser recriados com o comando rpm --rebuilddb.

# para descobrir o dbms usado pelo rpm
$ rpm --showrc

# para restaurar banco de dados corrompido
$ rpm --rebuilddb

O que é DNF5?

O DNF5 é um gerenciador de pacotes que automatiza o processo de instalação, atualização, configuração e remoção de programas de computador de forma consistente. Ele suporta pacotes RPM, módulos modulemd e grupos e ambientes comps. libdnf é a biblioteca de gerenciamento de pacotes, escrita originalmente para suportar o gerenciador de pacotes DNF, mas gradualmente cresceu e se tornou uma biblioteca versátil. Agora é possível usar libdnf para construir ferramentas personalizadas que carregam repositórios, resolvem dependências, consultam e instalam pacotes. O DNF5 também é alimentado pela biblioteca libsolv, que fornece uma interface de programação fácil de usar.

O DNF5 você pode trabalhar com os seguintes artefatos:

  • Repositórios e pacotes RPM: descritos acima.
  • Módulos modulemd: modulemd é um arquivo que define quais pacotes são construídos para cada versão do sistema operacional. Ele inclui um resumo e uma descrição, uma lista de pacotes RPM de origem, informações sobre a ordem em que os aplicativos são instalados, junto com macros e informações de uso, ou seja, perfis de instalação e licenças.
  • Ambientes e grupos comps, Metadados de composição da distribuição (Distribution Compose Metadata): Objetos comps reune informações sobre todos os repositórios disponíveis.
  • Avisos (updateinfo, erros): Avisos são mensagens informativas que não impedem a conclusão do comando DNF mas indicam problemas potenciais e sugerem alternativas. Updateinfo é um metadado com informações sobre atualizações disponíveis para pacotes. Quando o DNF encontra updateinfo, ele pode exibir informações sobre atualizações disponíveis, incluindo o nome do pacote, versão e repositório. Updateinfo não é um erro, mas sim uma notificação sobre atualizações disponíveis. Erros são mensagens críticas que impedem a conclusão do comando DNF. Eles podem informar da ausência de dependências, erros no repositório, etc.

Instalação

Para instalar o gerenciador de pacotes DNF5, use um dos seguintes comandos, dependendo da sua versão do Fedora. Verifique antes se ele já não está instalado.

# no Fedora 37 ou outro sistema sem a instalação do repositório
$ sudo dnf copr enable rpmsoftwaremanagement/dnf-nightly 
# instalando 
$ sudo dnf install dnf5

# no Fedora 38+ o repositório já está incluído
$ sudo dnf install dnf5
	
# verifique qual versão instalada, e em que diretório.
$ which dnf5
➡ /usr/bin/dnf5
 
# ou 
$ dnf5 --version
➡ dnf5 version 5.2.7.0
  dnf5 plugin API version 2.0
  libdnf5 version 5.2.7.0
  libdnf5 plugin API version 2.0
 [truncado]

Os seguintes comandos são de uso frequente com o dnf (usado como álias para o dnf5):

Comandos:

Comando, aliás Descrição
$ dnf upgrade <pacote> Atualiza o sistema e pacotes para a versão mais recente.
$ dnf search <pacote> Pesquisa pacotes disponíveis no repositório do sistema.
$ dnf install <pacote> Instala um nova pacote especificado pelo nome.
$ dnf remove <pacote> Remove pacotes instalados especificaods pelo nome.
$ dnf distro-sync <pacote> Sincronize os pacotes instalados com as versões mais recente disponíveis nos repositórios para a versão atual do Fedora.
$ dnf repoquery <pacote> Pesquisa a informação sobre o pacote especificado nos repositórios DNF.
$ dnf list <pacote> Exibe informações sobre pacotes que se ajustem à especificação.
$ dnf info <pacote> Coleta informação detalhada sobre o pacote especificado.
$ dnf makecache Refaz e atualiza o cache de metadata do gerente de pacotes DNF.
$ dnf repolist Exibe a lista de repositórios junto com informações sobre o número de pacotes disponíveis em cada repositório.
$ dnf repoinfo Exibe informação sobre os repositórios configurados no sistema.

As páginas do manual do aplicativo podem ser visualizados com man dnf, para ajuda geral, ou man dnf list para a ajuda sobre o parâmetro específico list ou outro qualquer.

Exemplos de uso do dnf

Alguns exemplos podem ajudar a compreender o uso do dnf. Observe que algumas operações exigem o uso do sudo.
O comando sudo (Super User DO) é usado como um prefixo para comandos que só podem ser executados por superusuários, aqueles que têm permissão. Isso faz com que o comando após o sudo seja executado com privilégios elevados. Vários usuários podem ter acesso ao sudo, desde que estejam declarados como administradores no arquivo sudoers em /etc/sudoers. Por padrão, esses usuários executam funções administrativas usando as suas próprias senhas.

upgrade, search, install, remove

No exemplo abaixo lidamos com a pesquisa, instalação e remoção do aplicativo featherpad, um editor de texto puro usando Qt.

Exemplos de uso:

# fazer a atualização do pacote featherpad
$ sudo dnf upgrade featherpad
➡ Updating and loading repositories:
  Repositories loaded.

# pesquisar pelo pacote nos repositórios cadastrados 
$ dnf search featherpad
➡ Updating and loading repositories:
  Repositories loaded.
  Matched fields: name (exact)
  featherpad.x86_64: Lightweight Qt Plain-Text Editor

# instalar a pacote, que deve estar nos repositórios cadastrados 
$ sudo dnf install featherpad
➡ Updating and loading repositories:
  Repositories loaded.
  Package                   Arch           Version         Repository         Size
  Installing:
featherpad              x86_64         1.5.1-1.fc41    fedora             3.4 MiB

  Transaction Summary:
   Installing:         1 package

  Total size of inbound packages is 893 KiB. Need to download 893 KiB.
  After this operation, 3 MiB extra will be used (install 3 MiB, remove 0 B).
  Is this ok [y/N]: y
# featherpad-0:1.5.1-1.fc41.x86_64 é instalado e pode ser usado
$ featherpad
                                                                                                                                  
# desinstalar o aplicativo featherpad
$ sudo dnf remove featherpad
➡ Package            Arch          Version         Repository            Size
  Removing:
   featherpad      x86_64           1.5.1-1.fc41   fedora                  3.4 MiB
  Transaction Summary:
Removing:  1 package
  Is this ok [y/N]: y
# o featherpad é removido do sistema

# para evitar que a execução seja interrompida por perguntas use
$ sudo dnf install featherpad -y
$ sudo dnf remove featherpad -y

Os comandos de instalação e remoção perguntam ao usuário: Is this ok [y/N]: , sendo que a resposta “Não” é o default. Para responder Yes para todas as perguntas use a chave -y (ou -n para responder No).

makecache, repolist, repoinfo

Também podemos gerenciar, inserindo ou removendo os repositórios cadastrados de acordo com as necessidades.

# para listar os repositórios cadastrados
$ dnf makecache
➡ Updating and loading repositories:
  Repositories loaded.
  Metadata cache created.
  
# para listar os repositórios cadastrados
$ dnf repolist
➡ repo id                                                            repo name
  copr:copr.fedorainfracloud.org:ryanabx:cosmic-epoch                 Copr repo for cosmic-epoch owned by ryanabx
  copr:copr.fedorainfracloud.org:wiiznokes:cosmic-applets-unofficial  Copr repo for cosmic-applets-unofficial owned by wiiznokes
  fedora                                                              Fedora 41 - x86_64
  fedora-cisco-openh264                                               Fedora 41 openh264 (From Cisco) - x86_64
  rpmfusion-free                                                      RPM Fusion for Fedora 41 - Free
  rpmfusion-free-updates                                              RPM Fusion for Fedora 41 - Free - Updates
  rpmfusion-nonfree                                                   RPM Fusion for Fedora 41 - Nonfree
  rpmfusion-nonfree-updates                                           RPM Fusion for Fedora 41 - Nonfree - Updates
  updates                                                             Fedora 41 - x86_64 - Updates

# para listar as propriedades dos repositórios
$ dnf repoinfo
➡ Updating and loading repositories:
  Repositories loaded.
  Repo ID             : copr:copr.fedorainfracloud.org:ryanabx:cosmic-epoch
  Name                : Copr repo for cosmic-epoch owned by ryanabx
  Status              : enabled
  Priority            : 99
  Cost                : 1000
  Type                : available
  Metadata expire     : 172800 seconds (last: 2024-11-15 14:08:04)
  Skip if unavailable : true
  Config file         : /etc/yum.repos.d/_copr:copr.fedorainfracloud.org:ryanabx:cosmic-epoch.repo
  URLs                :
Base URL          : https://download.copr.fedorainfracloud.org/results/ryanabx/cosmic-epoch/fedora-41-x86_64/
  PGP                 :
Keys              : https://download.copr.fedorainfracloud.org/results/ryanabx/cosmic-epoch/pubkey.gpg
Verify repodata   : false
Verify packages   : true
  Repodata info       :
   Available packages : 626
Total packages    : 626
Size              : 22.9 GiB
Revision          : 1731404232
Updated           : 2024-11-12 09:37:12
# [truncado] segue as descrições dos demais repositórios registardos no computador

O comando dnf makecache é usado para baixar metadados para os repositórios habilitados, atualizando os dados locais. Ele tenta evitar o download de novos dados sempre que possível, por exemplo, quando os dados locais ainda não expiraram ou quando o carimbo de data/hora não foram alterados.

repolist é um aliás para repo list (ou seja, list é um parâmetro do comando repo), usado para listar os repositórios cadastrados. Se nenhum repositório estiver configurado ele não apresenta nenhum retorno. Da mesma forma repoinfo é um aliás para repo info, listando repositórios e suas propriedades.

Glossário

Especificação de padrões

Globs: globs são padrões que especificam um comjunto de nomes de arquivos usando caracteres “curingas” ou wildcard. Os padrões aceitos pelo dnf são os mesmos usados pela shell. Os seguintes padrões podem ser usados.

Definições:

* casa com qualquer número de caracteres, ou vazio.
? casa com um caracter único.
[xyz] casa com x, y ou z; qualquer um dos caracteres entre colchetes.
[a-z] casa qualquer um dos caracteres entre a até z, inclusive.
[!a-z] ou [^a-z] não casa com nenhum dos caracteres na faixa de a até z.
{ } colchetes não são suportados.

Exemplos:

*.txt casa com qualquer nome de arquivo que termina com .txt, como “texto.txt”, “aa.txt” ou “.txt”.
su*.css casa com “su.css”, “superman.css” ou “sucata.css”.
?asa.toml casa com qualquer nome de arquivo como “casa.toml”, “rasa.toml” ou “sasa.toml”.
??uga.pdf casa com “aluga.pdf”, “_ruga.pdf” mas não casa com “beluga.pdf”.
[a-m]luga.hlmt casa com “aluga.hlmt”, “gluga.hlmt”, “kluga.hlmt”, mas não com “pluga.hlmt”.
[!1-5]fix.jpg não casa com “3fix.jpg” nem “5fix.jpg”, mas casa com “7fix.jpg”.
[^1-5]fix.jpg o mesmo que acima.

Padrão NEVRA

Pacotes podem ser identificados exclusivamente pela string NEVRA, que consiste de 5 partes de informação:
Name | Epoch | Version | Release | Architecture

São eles: name do pacote (pode conter hifens), Epoch, um número, timestamp, nem sempre incluído, Version uma string, alfanumérica,Release da versão, Architecture, string definindo arquitetura do alvo.

Packages (Pacotes)

Muitos comandos usam o parâmetro <package-spec> para selecionar pacotes. Esse argumento é comparado com NEVRAs de pacotes, provides e file provides. Quando <package-spec> é um nome de pacote ou um provide, o usuário pode fornecer regras adicionais de restrição para corresponder aos argumentos. Comparações de versão podem usar os operadores lógicos =, >, <, >=, <= como, por exemplo, <package-spec>>= <version>, onde o argumento <version> está no formato [EPOCH:]VERSION[-RELEASE] conforme especificado acima.

<package-file-spec> é similar a <package-spec>, exceto que provides matching não é executado. Portanto, <package-file-spec> é correspondido somente com NEVRAs e file provides. <package-name-spec> é correspondido somente com NEVRAs.

Bibliografia

Leave a Reply

Your email address will not be published. Required fields are marked *