Ilustração de um gerenciador de pacotes sendo usado para baixar novos softwares. As ações manuais podem incluir a aceitação de um contrato de licença ou a seleção de algumas opções de configuração específicas do pacote.

Um pacote de software é um arquivo de arquivo contendo um programa de computador, bem como os metadados necessários para a sua implantação. O programa de computador pode estar em código fonte que tem de ser compilado e compilado primeiro. Os metadados do pacote incluem descrição do pacote, versão do pacote e dependências (outros pacotes que precisam ser instalados antes).

Os gerentes de pacotes são encarregados da tarefa de encontrar, instalar, manter ou desinstalar os pacotes de software sob o comando do usuário. As funções típicas de um sistema de gerenciamento de pacotes incluem:

• Trabalhar com arquivadores de arquivos para extrair arquivos de pacotes
• Proteger a integridade e autenticidade do pacote verificando seus checksums e certificados digitais, respectivamente
• Localizar, baixar, instalar ou atualizar software existente de um repositório de software ou loja de aplicativos
• Agrupar pacotes por função para reduzir a confusão do usuário
• Gerenciar dependências para garantir que um pacote seja instalado com todos os pacotes que ele requer, evitando assim o “inferno da dependência”

Desafios com bibliotecas compartilhadasEditar

Sistemas de computadores que dependem da ligação de bibliotecas dinâmicas, em vez da ligação de bibliotecas estáticas, compartilham bibliotecas executáveis de instruções de máquina entre pacotes e aplicações. Nestes sistemas, relações complexas entre diferentes pacotes que requerem diferentes versões de bibliotecas resultam em um desafio coloquialmente conhecido como “inferno de dependências”. Em sistemas Microsoft Windows, isto também é chamado de “inferno de DLL” quando se trabalha com bibliotecas ligadas dinamicamente. Um bom gerenciamento de pacotes é vital nestes sistemas. O sistema Framework da OPENSTEP foi uma tentativa de resolver este problema, permitindo que múltiplas versões de bibliotecas fossem instaladas simultaneamente, e que pacotes de software especificassem qual versão estavam ligados contra.

Front-ends para pacotes compilados localmenteEditar

Os administradores de sistemas podem instalar e manter software usando outras ferramentas que não software de gerenciamento de pacotes. Por exemplo, um administrador local pode baixar o código fonte descompactado, compilá-lo e instalá-lo. Isto pode fazer com que o estado do sistema local caia fora da sincronização com o estado do banco de dados do gerenciador de pacotes. O administrador local deverá tomar medidas adicionais, tais como gerenciar manualmente algumas dependências ou integrar as alterações no gerenciador de pacotes.

Existem ferramentas disponíveis para garantir que os pacotes compilados localmente sejam integrados com o gerenciamento de pacotes. Para distribuições baseadas em arquivos .deb e .rpm, assim como no Slackware Linux, existe o CheckInstall, e para sistemas baseados em receitas como o Gentoo Linux e sistemas híbridos como o Arch Linux, é possível escrever uma receita primeiro, o que então garante que o pacote se encaixe no banco de dados de pacotes local.

Manutenção da configuraçãoEdit

Particularmente problemático com atualizações de software são as atualizações de arquivos de configuração. Como os gerenciadores de pacotes, pelo menos em sistemas Unix, originados como extensões de utilitários de arquivamento de arquivos, eles normalmente só podem sobrescrever ou reter arquivos de configuração, ao invés de aplicar regras a eles. Existem excepções a este ?que normalmente se aplicam à configuração do kernel (que, se quebrada, tornará o computador inutilizável após um reinício). Problemas podem ser causados se o formato dos arquivos de configuração mudar; por exemplo, se o arquivo de configuração antigo não desabilitar explicitamente novas opções que devem ser desabilitadas. Alguns gerenciadores de pacotes, como o dpkg do Debian, permitem a configuração durante a instalação. Em outras situações, é desejável instalar pacotes com a configuração padrão e então sobrescrever esta configuração, por exemplo, em instalações sem cabeça para um grande número de computadores. Este tipo de instalação pré-configurada também é suportado pelo dpkg.

RepositoriesEdit

Para dar aos utilizadores mais controlo sobre os tipos de software que estão a permitir que sejam instalados no seu sistema (e por vezes devido a razões legais ou de conveniência do lado dos distribuidores), o software é muitas vezes descarregado a partir de vários repositórios de software.

Upgrade suppressionEdit

Quando um usuário interage com o software de gerenciamento de pacotes para trazer uma atualização, é costume apresentar ao usuário a lista de ações a serem executadas (geralmente a lista de pacotes a serem atualizados, e possivelmente dando os números das versões antiga e nova), e permitir que o usuário aceite a atualização em massa, ou selecione pacotes individuais para atualizações. Muitos gerenciadores de pacotes podem ser configurados para nunca atualizar certos pacotes, ou para atualizá-los somente quando vulnerabilidades ou instabilidades críticas forem encontradas na versão anterior, como definido pelo empacotador do software. Este processo é às vezes chamado de pino de versão.

Por exemplo:

• yum suporta isto com a sintaxe exclude=openoffice*
• pacman com IgnorePkg= openoffice (para suprimir a actualização do openoffice em ambos os casos)
• dpkg e dselect suportam isto parcialmente através da bandeira hold em seleções de pacotes
• APT estende a bandeira hold através do complexo mecanismo de “pinning” (Usuários também podem colocar um pacote na lista negra)
• aptitude tem as bandeiras “hold” e “proibir”
• portage suporta isso através do pacote.mask configuration file

Cascading package removalEdit

Algumas das funcionalidades mais avançadas de gestão de pacotes oferecem “cascading package removal”, no qual todos os pacotes que dependem do pacote alvo e todos os pacotes dos quais apenas o pacote alvo depende, também são removidos.

Comparação de comandosEdit

Embora os comandos sejam específicos para cada gestor de pacotes em particular, eles são em grande parte traduzíveis, uma vez que a maioria dos gestores de pacotes oferecem funções semelhantes.

O Arch Linux Pacman/Rosetta wiki oferece uma visão extensiva.