MOSS – ISCTE – FSOCA - 2010

Gestão de Pacotes

Carlos Rosão, Rui Figueiredo, Tiago Mestre

“[Package Management] is the the single biggest advancement Linux has brought to the industry”1

Ian Murdock

Prof. Paulo Trezentos

1 “[A Gestão de Pacotes] é o desenvolvimento mais importante que o Linux trouxe à indústria.“ - Ian Murdock, criador inicial da distribuição de Linux Debian[1].

1

ÍndiceIntrodução.............................................................................................................................................2Pacotes..................................................................................................................................................3

Criação de Pacotes...........................................................................................................................3Repositórios.....................................................................................................................................5

Gestão de Pacotes.................................................................................................................................6Back-end vs Front-end.....................................................................................................................6Funcionamento Geral.......................................................................................................................7Família de Distribuições Red Hat....................................................................................................8Família de Distribuições Debian......................................................................................................9Gestores de Pacotes Menos Comuns.............................................................................................10Uma Separação Frágil....................................................................................................................11Ambientes Gráficos.......................................................................................................................12

Conclusão...........................................................................................................................................13Bibliografia.........................................................................................................................................14Referências.........................................................................................................................................14Links...................................................................................................................................................14Anexo I – Problemas de segurança em Pacotes.................................................................................16Anexo II – Exemplo concreto de utilização de apt.............................................................................17

Índice de FigurasFigura 1: Semelhanças entre criação de .deb e .rpm............................................................................3Figura 2: Funcionamento Geral de um Gestor de Pacotes. Fonte: http://en.opensuse.org/Package_management......................................................................................8Figura 3: Imagem do Synaptic 0.62, no Debian 5.0.0, que mostra os pacotes da categoria 'System Administration'. Fonte: Wikimedia Commons...................................................................................12

Índice de TabelasTabela 1: Gestores de Pacotes - Back-end vs Front-end .....................................................................7

2

IntroduçãoAntes de se poder entender o significado de um gestor de pacotes, a primeira questão que se

coloca é: “o que é um pacote?”.Em termos informáticos, um pacote é algo semelhante ao conceito físico que temos do mesmo:

algo para guardar informação relacionada entre si de alguma forma. Isto é ambos contêm “dentro de si” informação relacionada, necessitam de ser “abertos” antes que essa informação possa ser utilizada e ambos podem ter uma etiqueta “exterior” que identifique o seu conteúdo.

Portanto, de forma bastante geral e resumida, em termos informáticos, podemos considerar um pacote como sendo um conjunto de ficheiros relacionados contendo informação sobre como devem ser utilizados.

Na maior parte das vezes um pacote contém uma aplicação ou um conjunto de aplicações (é nesses pacotes que nos iremos focar primariamente neste trabalho), no entanto um pacote pode conter simplesmente documentação ou um conjunto de temas para o ambiente de trabalho, fontes, etc.

Um pacote contém informação sobre em que directorias do sistema de ficheiros o seu conteúdo deverá residir, dependências e conflitos que o seu conteúdo traz associados, e ainda instruções de instalação do seu conteúdo.

No caso concreto dos pacotes de aplicações, estes contêm o código fonte pré-compilado1 e empacotado como um arquivo binário de instalação (executável). Estes pacotes podem conter ainda ícones, bibliotecas, arquivos de configuração, binários, man pages2,atalhos de ambiente de trabalho, headers, fontes, etc... Além disso, um pacote pode conter meta-dados, como por exemplo, informações sobre a versão, identificação do autor do software, quem mantém o pacote, informações do contacto, licenciamento, alterações, Readme’s e o site do projecto e do código fonte.

De forma sistematizada um pacote é composto por três partes:[16]● Ficheiros que correspondem à aplicação propriamente dita (incluindo ficheiros de configuração);

● Meta-dados (incluindo dependências);● Scripts de configuração e manutenção;

Quando um pacote é instalado (através de qualquer um dos gestores de pacotes que falaremos em baixo), os dados são descompactados e copiados para as directorias necessárias do sistema de ficheiros (estas directorias diferem de distribuição para distribuição), criando links simbólicos onde necessário, atalhos nos menus e no ambiente de trabalho e também disponibilizando opções de configuração ao utilizador.

Porquê a utilização de pacotes?Um computador tem capacidade para trabalhar com grandes quantidades de informação, no

entanto se esta estiver desorganizada, a facilidade de remoção ou de edição de informação torna-se uma tarefa bastante penosa.

Portanto, de entre as principais vantagens da utilização de pacotes, destacam-se:● Possibilidade de mobilidade de informação sem perda de dados;● Facilidade de organização e de estrutura da informação;● “Auto-suficiência” – um pacote contém informação sobre como “se instalar” e “desinstalar” do sistema, tornando estas tarefas mais simples;

1 Pode-se guardar num pacote o código fonte sem ser compilado, mas é muito mais comum guardar-se de forma já pré-compilada.

2 As man pages são manuais/sistemas de ajuda que podem ser consultados através da consola.

3

Sendo assim, hoje em dia, a utilização de pacotes e, consequentemente, de gestores de pacotes torna-se uma obrigação que pode ser resumida na frase:

“Manage Your Packages, or They Will Manage You”1

Pacotes

Criação de PacotesComo veremos de seguida, existem vários tipos de pacotes e, consequentemente de gestores

de pacotes, no entanto o seu processo de criação baseia-se em princípios comuns, tal como está representado esquematicamente na Figura 1.

Para a criação de um pacote são necessários o código fonte da aplicação e ainda um ficheiro de controlo2 (estes ficheiros de controlo podem ser criados dinamicamente através de Geradores de Ficheiros de Controlo) que serve como se fosse a receita para a criação do pacote. Este ficheiro de controlo é um simples ficheiro de texto, no entanto é extremamente importante, pois é ele que informa como se cria o pacote, por outro lado contém também meta-dados que não são necessários para o processo de criação do pacote mas que, no entanto, dão informação útil ao utilizador.

O ficheiro de controlo está normalmente estruturado com o seguinte conteúdo: [2], [10]● Conjunto descritivo (deste conjunto, só os campos com o nome, versão e release têm relevo na criação verdadeiramente dita do pacote, os outros campos têm apenas utilidade como informação para o utilizador)

○ Nomenclatura do pacote (nome, criador, versão, etc.)○ Descrição (descrição completa, sumário, copyright, etc.)○ Dependências (pacotes que providencia, pacotes dos quais depende, conflitos, etc.)

○ Arquitectura/Sistema operativo (para que sistema operativo, versão do mesmo, e arquitectura de pc está a ser criado)

1 “Gere os teus pacotes caso contrário eles gerem-te a ti” - http://www.rpm.org/max-rpm/ch-intro-to-rpm.html2 No gestor rpm o ficheiro de controlo é um .spec e no caso do dpkg é um control file.

Figura 1: Semelhanças entre criação de .deb e .rpm

4

○ Estrutura de ficheiros (caminhos no sistema de ficheiros a serem usados durante a instalação)

○ Código fonte e Patches (indica o caminho ou caminhos para o código de fonte e patches)

● Conjunto de scripts de criação/instalação e remoção (aceita alguns macros pré-definidos e shell scripts)

○ Secção %prep – nesta secção prepara-se o pacote para ser construído.○ Secção %build – esta secção contém a parte que constrói (build) o pacote, normalmente através da ferramenta make.

○ Secção %install – é nesta secção que se coloca o script de instalação do programa, normalmente faz-se uso da ferramenta make install.

○ Secção %files – contém a lista dos ficheiros que pertencem ao pacote. Esta lista necessita de ser criada manualmente.

○ Secções de instalação/desinstalação dos scripts – outros scripts que correm depois/antes do pacote ser instalado/removido

○ Secção %clean – limpa alguns ficheiros temporários que são criados durante a instalação

Um ficheiro de controlo, no caso de um rpm, pode tomar a seguinte forma (para um deb, o formato é semelhante), onde as linhas iniciadas por # são comentários: [10]#

# Example spec file for cdplayer app...

#

Summary: A CD player app that rocks!

Name: cdplayer

Version: 1.0

Release: 1

Copyright: GPL

Group: Applications/Sound

Source: ftp://ftp.gnomovision.com/pub/cdplayer/cdplayer-1.0.tgz

URL: http://www.gnomovision.com/cdplayer/cdplayer.html

Distribution: WSS Linux

Vendor: White Socks Software, Inc.

Packager: Santa Claus <sclaus@northpole.com>

%description

It slices! It dices! It's a CD player app that

can't be beat. By using the resonant frequency

of the CD itself, it is able to simulate 20X

oversampling. This leads to sound quality that

cannot be equaled with more mundane software...

5

# It is in the %prep section that the build environment for the software is created, starting with removing the remnants of any previous builds. Following this, the source archive is expanded. It can use shell scripts or a pre-defined macro, like %setup

%prep

%setup

#Like the %prep section, the %build section is an ordinary sh script. Unlike the %prep section, there are no macros that can be used here.

%build

make

#The %install section is executed as a sh script, just like %prep and %build. If the application is built with make and has an "install" target, the %install section will also be straightforward.

%installmake install

#The %files section is different from the others, in that it contains a list of the files that are part of the package.

%files

%doc README

/usr/local/bin/cdp

/usr/local/bin/cdplay

/usr/local/man/man1/cdp.1

#Install-uninstall scripts

#insert here any other scripts to run on install or uninstall

%clean

#here goes the script to clean temporary files that were created during the build process

Com a informação anterior, o gestor de pacotes consegue através dos seus scripts internos, criar um pacote.

RepositóriosOs repositórios são como que arquivos onde estão armazenadas colecções de pacotes

acessíveis para os utilizadores poderem descarregar e utilizar. Normalmente os repositórios encontram-se localizados num servidor remoto, mas podem também estar armazenados num disco rígido, CD-ROM, DVD ou outro tipo de dispositivos de armazenamento.

Para ser possível aceder a um repositório remoto é necessária, normalmente, uma chave digital - por exemplo o sistema apt das distribuições baseadas em Debian utiliza o sistema gpg GNU Privacy Guard [3] (no Anexo I – Problemas de segurança em Pacotes apresentam-se alguns dos principais problemas no que à segurança de pacotes diz respeito) e, como estes

6

repositórios são mantidos por uma organização/pessoa confiável, estão, em princípio, livres de malware, vírus e similares. Esta é uma das principais razões pelas quais os sistemas operativos que utilizam de forma generalizada os repositórios e gestores de pacotes, estarem menos sujeitos a este tipo de ataques.

Para que os gestores de pacotes se consigam “orientar”, os repositórios precisam de ter uma organização muito estruturada.

Os repositórios oficiais das distribuições de Linux têm uma estrutura muito própria, por exemplo, os repositórios da distribuição Ubuntu encontram-se organizados da seguinte forma:

• Main - Software oficialmente suportado.• Restricted - Software suportado, mas que não está disponível sob uma licença

completamente livre (pode fazer uso de bibliotecas privadas, por exemplo).• Universe - Software não suportado oficialmente, mas mantido e suportado pela

comunidade.• Multiverse - Software não livre.

É importante notar que os repositórios armazenam pacotes num formato específico, dependendo do gestor de pacotes para os quais são construídos. Por exemplo, o urpmi do Mandriva não consegue ler o repositório yum do Fedora, embora ambos contenham pacotes no formato .rpm.

Gestão de PacotesDe forma resumida, um gestor de pacotes, é uma aplicação (ou um conjunto de aplicações)

responsável por facilitar e automatizar as tarefas de instalar, remover, configurar e actualizar pacotes.

Hoje em dia, grande parte dos gestores de pacotes utilizados faz bem mais do que isto, no entanto é importante entender como funcionam de raiz, pois, na realidade, qualquer um dos actuais funciona tendo por base os gestores de pacotes mais limitados que foram criados há mais tempo.

Back-end vs Front-end1

Durante os anos 90, foram criados os primeiros gestores de pacotes que tinham por objectivo simplificar o processo de instalação de aplicações a partir dos códigos-fonte, tal como o processo de remoção dos pacotes instalados.

Estes gestores tratavam de, de forma prática e rápida, instalar ou remover um pacote criado de acordo com as instruções que referimos no capítulo Criação de Pacotes.

Dos gestores de pacotes que apareceram nessa altura e que continuam a ter grande importância hoje em dia destacam-se:

● rpm (originalmente desenvolvido pela Red Hat e denominado Red Hat Package Manager, que mais tarde passou a ser um acrónimo recursivo para RPM Package Manager) → responsável por pacotes .rpm

● dpkg (abreviatura de Debian Package, desenvolvido por Matt Welsh, Carl Streeter e Ian Murdock, tendo sido mais tarde aperfeiçoado pela comunidade) → responsável por pacotes .deb

1 Nalguma literatura, por exemplo [14], utilizam-se os termos installer para representar back-end e meta-installer para representar front-end.

7

Existem ainda outros tipos de pacotes menos utilizados, mas não menos importantes, dos quais podemos referir, a título de exemplo:

● ebuild - formato próprio da distribuição Gentoo.● pkg.tar.xz - utilizado pela distribuição Arch Linux e pelo seu gestor de pacotes Pacman.● tgz - Junção dos ficheiros .tar e .gz utilizado em várias distribuições, mas primariamente pela Slackware.

Os gestores de pacotes iniciais representaram um passo extremamente importante no desenvolvimento do Linux, no entanto têm algumas limitações, sendo que uma das principais é não terem em conta as dependências inerentes a cada pacote, ou seja têm em conta apenas pacotes individuais. Isto significa que, se utilizarmos apenas estas ferramentas para as tarefas de instalação e remoção de pacotes no nosso sistema, existe uma probabilidade muito grande de ficarmos com pacotes repetidos e/ou a ter muita dificuldade em instalar certos pacotes, devido a termos de procurar manualmente pelas suas dependências específicas – este tipo de problema costuma apelidar-se de Dependency Hell [8].

Devido a este tipo de limitações, ao longo dos anos foram aparecendo novos gestores de pacotes que expandem as funcionalidades dos gestores originais.

Na realidade, talvez seja mais correcto não chamar 'gestores novos' a estas aplicações, uma vez que elas são como que um front-end1 entre o utilizador e o gestor de pacotes original (utilizado nestas condições como um back-end).

Está patente, na Tabela 1, a título de exemplo, quais são os back-end e os principais front-end nas duas famílias de distribuições de Linux mais utilizadas hoje em dia.

Distribuições baseadas em Debian Distribuições baseadas em Red Hat

Back-end dpkg rpm

Front-endapt

aptidudesmart

yumzyppsmart

Tabela 1: Gestores de Pacotes - Back-end vs Front-end

Funcionamento GeralIndependentemente do seu back-end, para além de instalar, remover e actualizar pacotes, um

Gestor de Pacotes actual pode ligar-se directamente a um repositório, descarregar pacotes, verificar e resolver as suas dependências, pesquisar na lista de pacotes e editar a lista de repositórios que utiliza. É ainda possível indicar um repositório para um pacote específico e bloquear actualizações de outros pacotes, verificar o checksum2. e as assinaturas digitais - garantindo assim a integridade dos pacotes, fazer actualizações automáticas e remover dependências ao desinstalar programas.

Na Figura 2 podemos ver como funciona, em termos esquemáticos, a ligação do gestor de pacotes a um repositório.

A interacção do gestor de pacotes com um repositório é feita por pedidos. Portanto quando um utilizador quer instalar um determinado pacote recorrendo ao gestor de pacotes, acontece algo que se pode esquematizar da seguinte forma:

1 Um front-end é uma espécie de intermediário entre o utilizador e a aplicação base (também chamada de back-end nestas condições).

2 O checksum ou hash-code é um bloco de dados de tamanho fixo criado a partir de um conjunto de dados originais, para verificação de erros introduzidos nos dados originais aquando da sua transferência ou armazenamento. A verificação da integridade dos dados pode ser executada em qualquer altura através da criação de um checksum a partir dos novos dados e comparando-o com o checksum original.

8

1. Gestor de pacotes faz um pedido ao repositório por informação relativamente ao pacote;2. O repositório envia os meta-dados correspondentes ao pacote escolhido (contendo

informação referente ao tamanho do pacote, às suas dependências, aos seus conflitos, etc.);

3. O gestor de pacotes recebe os meta-dados do servidor e guarda-os na sua base de dados interna (no caso do rpm, a sua base de dados é do tipo Berkeley DB)

4. Utilizando a sua base de dados, o gestor de pacotes envia ao repositório pedidos de descarregamento para todos os pacotes necessários (de acordo com a informação recebida sobre as dependências);

5. Por fim, quando tudo tiver sido descarregado, o gestor procede à instalação dos pacotes que descarregou;

Os gestores de pacotes actuais, são todos muito similares em termos de funcionalidades, o que significa que as diferenças principais entre si prendem-se por pormenores e também um pouco por gosto do utilizador em si ou de quem estrutura o conteúdo da distribuição.

Família de Distribuições Red HatPara a família de distribuições baseadas em Red Hat, os front-ends mais utilizados são o yum

e o zypp.

Yellow Dog Updater Modified (yum) - Usado nas distribuições Fedora, CentOS, Red Hat Enterprise Linux 5 e superiores, Scientific Linux, Yellow Dog Linux, Oracle Enterprise Linux, etc.

Este gestor, desenvolvido por Seth Vidal juntamente com um grupo de voluntários, tem bastante importância pois o seu repositório no formato XML, construído com o feedback de muitos programadores, tornou-se o standard dos repositórios baseados em RPM.

De seguida listam-se alguns dos comandos responsáveis pelas tarefas mais utilizadas com o yum:

Instalar/Remover pacote:1

# yum install pacote# yum remove pacoteActualizar sistema:

1 No resto do texto, sempre que forem referidos comandos de consola, a terminologia utilizada é a seguinte:- o símbolo '#' no início da linha significa que o comando é executado como root- o símbolo '$' no início da linha significa que o comando é executado como utilizador comum.

Figura 2: Funcionamento Geral de um Gestor de Pacotes. Fonte: http://en.opensuse.org/Package_management

9

# yum updateProcurar pacote (aceita regular expressions)$ yum list pacoteDescobrir a que pacote o ficheiro pertence:$ yum provides ficheiro

A configuração do yum é obtida através da manipulação do ficheiro: /etc/yum.conf

ZYpp (ou libzypp) - é o gestor de pacotes padrão do SUSE e do OpenSuse e usa pacotes .rpm. Para este gestor de pacotes existe o Zypper (Uma interface de linha de comandos), que permite instalar, remover, actualizar e procurar pacotes de programas.

Instalar pacote# zypper install package_nameRemover pacote# zypper remove package_nameActualizar sistema# zypper update

Quanto ao ficheiro que controla a configuração do zypper, este pode ser encontrado na directoria: /etc/zypp/zypper.conf

Família de Distribuições DebianPor outro lado, nas famílias de distribuições baseadas em Debian, os front-end mais utilizados

são apt (Advanced Packaging Tools) e aptitude, no entanto antes destes serem criados, outros existiam, por exemplo, um dos primeiros front-end a ser criado para o dpkg foi o dselect, cujo primeiro lançamento remonta a 1995, no entanto hoje em dia pode considerar-se obsoleto e caiu em desuso.

O apt surgiu pela primeira vez em 1999 na versão 2.1 da distribuição Debian; daí para cá tem vindo a melhorar as suas funcionalidades e a expandir-se por outras distribuições.

As funcionalidades executadas pelos front-end do gestor de pacotes RPM, também existem de forma equivalente no front-end apt, nomeadamente:

Instalar/remover pacote:# apt-get install pacote# apt-get remove pacoteActualizar lista de pacotes:#apt-get updateActualizar sistema:#apt-get upgradeProcurar por um pacote (aceita regular expressions).$ apt-cache search pacoteVer informação sobre um pacote instalado$ apt-cache show pacote

10

Como quase todos os programas de linux, o apt é também bastante configurável. A forma mais fácil de aceder e editar as suas configurações é através visualização ou edição dos seguintes ficheiros:

● /etc/apt/sources.list - contém a lista de locais onde se encontram os repositórios● /etc/apt/apt.conf - configuração base do apt● /etc/apt/preferences - aqui pode-se definir o “pinning”, isto é, é possível forçar o apt a ir buscar certas versões específicas de pacotes ou ir buscar a certos repositórios específicos.

Nas directorias seguintes, podemos aceder aos pacotes descarregados pelo apt:● /var/cache/apt/archives/ - aqui ficam guardados os pacotes descarregados pelo apt● /var/cache/apt/archives/partial/ - aqui ficam guardados, enquanto estão a ser instalados, os pacotes descarregados pelo apt

No Anexo II – Exemplo concreto de utilização de apt apresenta-se um exemplo prático da utilização do apt para a instalação de um repositório e de um pacote desse mesmo repositório na distribuição Ubuntu.

Quanto ao aptitude, este foi criado como sendo não um front-end directo para o dpkg, mas sim como um interface (em modo de texto) para o apt. As suas funcionalidades são bastante semelhantes às do apt, porém há quem defenda que o seu sistema de resolução de dependências é mais eficaz [4].

Quanto às funcionalidades mais utilizadas pelos gestores de pacotes tradicionais, estas podem ser obtidas no aptitude utilizando os seguinte comandos:

Actualização da lista de pacotes a partir dos repositórios# aptitude -u (sudo aptitude update)Actualização de todos os pacotes instalados# aptitude -U (sudo aptitude upgrade)Remover pacote# sudo aptitude remove pacoteInstalar pacote# sudo aptitude install pacoteProcurar por um pacote (aceita expressões regulares)$ aptitude search pacote

A configuração do aptitude pode ser personalizada editando o ficheiro/etc/apt/apt.conf

Gestores de Pacotes Menos ComunsExistem ainda outros sistemas menos convencionais de gestão de pacotes. Um exemplo

desses gestores é o Pkgtool, o gestor de pacotes padrão da distribuição Gnu/Linux Slackware. Ele é usado na instalação da distribuição e é também utilizado para a remoção, instalação e actualização de pacotes. Este gestor foi desenvolvido por Patrick J. Volkerding.

Outro sistema de gestão de pacotes pouco convencional é o Portage - um sistema desenvolvido na linguagem de programação Python e utilizado pela distribuição Gentoo Linux. Este gestor de pacotes tem uma série de recursos avançados, incluindo resolução de

11

dependências, uma gestão de pacotes optimizada, fake installs (ao estilo de OpenBSD), pacotes virtuais, etc.

Normalmente o Portage é utilizado através de um interface de linha de comandos denominado emerge.

Uma Separação FrágilA distinção entre pacotes dpkg e rpm não é muito definida como talvez pareça à primeira vista.

Esta falsa divisão pode logo começar a ser posta em causa quando se tem em conta que ambos os tipos de pacotes são criados da mesma forma (tal como vimos no capítulo Criação dePacotes).

Para a fragilidade desta separação contribuem os gestores de pacotes que conseguem trabalhar como front-end quer para dpkg quer para rpm. Um dos exemplos mais comuns com este tipo de funcionalidade é o gestor de pacotes smart.

O smart começou a ser desenvolvido em 2004, porém a sua versão 1.0 apenas viu a luz do dia em 2008. Este gestor de pacotes foi construído com o objectivo de poder ser utilizado em diversas distribuições de Linux e também em Macintosh. Para além disso, os seus criadores defendem que é bastante mais eficaz a resolver dependências do que os gestores nativos das distribuições onde for utilizado, por exemplo o yum ou o apt. [5]

De notar que o smart, apesar de poder ser utilizado em diversas distribuições de Linux, só funciona com os pacotes nativos dessa distribuição.

Para além do smart, existe também o projecto apt-rpm que é a transposição do front-end apt para funcionar tendo por base o back-end rpm [6] e que é utilizado por base em algumas distribuições de Linux, como Caixa Mágica ou o PCLinuxOS. [9]

Existe ainda o packagekit, uma interface que utiliza uma API1 independente da distribuição onde está instalada e dos formatos de pacotes binários. Ela pode ser utilizada como interface gráfico para o Conary, Apt, Yum, Box, Alpm entre outros. É importante notar que esta interface não foi concebido para substituir esses gestores de pacotes, mas sim para criar um nível de abstracção para um melhor funcionamento.

Por fim, existe ainda a possibilidade de converter entre os formatos inerentes aos gestores rpm e dpkg (e a outros gestores também) através de uma ferramenta denominada Alien [7].

O Alien suporta conversões entre Linux Standart Base, RPM, deb, Stampede (.slp), Solaris (.pkg) e Slackware (.tgz). Também permite instalar automaticamente os pacotes gerados pelas conversões e converter os scripts de instalação incluídos no arquivo.

Um exemplo comum de conversão de um pacote dpkg para rpm é feito através do comando:# alien --to-rpm --scripts ./pacote.deb

Apercebemo-nos que realmente existe uma fronteira entre diferentes tipos de pacotes mas que, por vezes, ela pode ser contornada com recurso às diversas ferramentas que enumerámos.

1 API representa Application Programming Interface (ou Interface de Programação de Aplicações)

12

Ambientes Gráficos

Com a expansão do Linux nos últimos anos e a sua consequente chegada ao utilizador menos especializado, tornou-se necessária a criação de ambientes gráficos (GUI) para os gestores de pacotes.

Desta forma apareceram, entre outros:● Synaptic Package Manager – Representado na Figura 3 e que reproduz todas as funcionalidades do gestor apt através de um ambiente gráfico. É utilizado em quase todas as distribuições descendentes do Debian.

● Yast – Baseado no gestor de pacotes rpm e que é característico das distribuições OpenSUSE;

● Ubuntu Software Center - uma simplificação e proposta de substituição do Synaptic por parte da distribuição Ubuntu.

Qualquer uma destas aplicações torna a tarefa de gerir pacotes extremamente amiga do utilizador, não tendo por requisitos, à priori, grandes conhecimentos técnicos do funcionamento interno da gestão de pacotes em si.

As aplicações gráficas que se referiram não trazem nenhuma funcionalidade nova propriamente dita, no entanto são úteis e uma mais valia para o utilizador comum, pois permitem ter uma visualização concreta do sistema de gestão de pacotes para quem não sabe ou não quer utilizar a linha de comandos.

Figura 3: Imagem do Synaptic 0.62, no Debian 5.0.0, que mostra os pacotes da categoria 'System Administration'. Fonte: Wikimedia Commons

13

ConclusãoA gestão de pacotes constituiu um dos maiores desenvolvimentos da história do Linux e

representa, hoje em dia, um pilar sobre o qual assentam todas as distribuições.Para além de todas as suas vantagens técnicas, o gestor de pacotes torna o sistema muito

mais amigo do utilizador, pois permite que as tarefas antigamente penosas de gestão de pacotes, sejam todas automatizadas, requerendo o mínimo de atenção por parte do utilizador.

Todavia, para o utilizador mais experiente que pretende controlar todos os passos relacionados com as alterações dos pacotes, os gestores de pacotes também permitem que isso seja feito.

É também relevante apontar que os gestores de pacotes tiveram um enorme sucesso que pode ser medido pela sua influência diagonal a todas as distribuições de Linux ou notando a sua influência em inúmeras áreas, desde a gestão de plugins em diversas aplicações (por exemplo o Eclipse ou o Quantum GIS) até à sua chegada a outros sistemas operativos, como o Windows[11] ou o Macintosh.

Neste momento o desenvolvimento dos gestores de pacotes não está parado. Existem várias equipas que tentam criar novas funcionalidades ou corrigir alguns problemas actuais, por exemplo relacionados com o rollback1, especialmente nos casos das actualizações de distribuição, ou relacionados com a segurança inerente aos pacotes em si, aos gestores e aos repositórios.

Como vimos anteriormente, existe ainda a tentativa de unificação dos pacotes das diferentes distribuições, existindo já passos nessa direcção, como a criação do Linux Standard Base [LSB] pela Linux Foundation [12], que definiu que todos os pacotes fossem distribuídos sob a forma de um rpm standardizado ou que disponibilizassem um instalador de acordo com as especificações da LSB[13]. No entanto nem todos aceitam este tipo de standards e alguns “violam” explicitamente as regras propostas pela LSB, como são os casos das distribuições que distribuem os seus pacotes nos formatos .deb ou .tg.gz.

Se esta unificação será bem sucedida, só o futuro o dirá.

O facto de muitos de nós darmos a gestão de pacotes como sendo algo garantido à partida, de tal forma que há quem assuma não poder viver sem ela, resume perfeitamente a sua extrema importância nos dias de hoje.

1 Rollback significa a possibilidade de anular as mudanças e voltar para um estado prévio de estado do sistema.

14

BibliografiaJosep Jorba Esteve, Remi Suppi Boldrito - “GNU/Linux Advanced Administration”

Referências[1] http :// ianmurdock . com / solaris / how - package - management - changed - everything / [2] http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html[3] http://www.gnupg.org/[4] http://pthree.org/2007/08/12/aptitude-vs-apt-get/[5] http :// labix . org / smart [6] http :// apt - rpm . org / about . shtml [7] http://kitenet.net/~joey/code/alien/[8] http://en.wikipedia.org/wiki/Dependency_hell [9] http://en.wikipedia.org/wiki/Apt-rpm[10] http://www.rpm.org/max-rpm/s1-rpm-build-creating-spec-file.html [11] http://technet.microsoft.com/en-us/library/cc748979%28WS.10%29.aspx [12]http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-

generic/swinstall.html [13]http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-

generic/pkgformat.html[14] Trezentos et al - “New Generation of Linux Meta-installers ”http://people.caixamagica.pt/paulotrezentos/articles/FOSDEM2007/FOSDEM2006_v3.pdf [15] http://www.cs.arizona.edu/stork/packagemanagersecurity/[16] Roberto di Cosmo, Stefano Zacchiroli, Paulo Trezentos - “Package Upgrades in FOSS

Distributions: Details and Challenges ”

Linkshttp :// en . wikipedia . org / wiki / Linux _ package _ formats http :// en . wikipedia . org / wiki / Software _ package _%28 installation %29 http :// www . linux . com / archive / articles /49405 http :// en . wikipedia . org / wiki / Package _ management _ system http :// en . wikipedia . org / wiki / List _ of _ software _ package _ management _ systems http :// en . wikipedia . org / wiki / Package _ manager http :// www . guiadohardware . net / dicas / gerenciamento - pacotes . html http :// pt . wikipedia . org / wiki / Pkgtool http :// en . wikipedia . org / wiki / Software _ repository http :// www . linuxforums . org / forum / newbie /93595- deb - vs - rpm . htm lhttp :// distrowatch . com / dwres . php ? resource = package - management http :// www . linuxplanet . com / linuxplanet / tutorials /6546/1/ http :// en . wikipedia . org / wiki / RPM _ Package _ Manager http :// en . wikipedia . org / wiki / Smart _ Package _ Manager http :// en . wikipedia . org / wiki / Dpkg http :// en . wikipedia . org / wiki / Synaptic _ Package _ Manager http :// en . wikipedia . org / wiki / Advanced _ Packaging _ Tool http :// luv . asn . au / overheads / aptitude / aptitude - intro . html

15

https :// help . ubuntu . com / community / SecureApt http :// ubuntuguide . org / wiki / Ubuntu : Maverick http :// en . wikipedia . org / wiki / Alien _( software ) http :// cnx . org / content / m 10468/ latest / http://en.wikipedia.org/wiki/Apt-rpm http://www.packagekit.org/pk-intro.html

16

Anexo I – Problemas de segurança em PacotesAs vulnerabilidades de segurança estão associadas, em grande parte, a bugs de código.

Sendo assim, é vital que tenhamos o software na sua versão mais recente. Os gestores de pacotes foram criados para, entre outras funcionalidades, ajudar nesta importante tarefa.

Há que ter em conta que, como os gestores de pacotes correm com permissões de root, se não forem seguros, podem pôr gravemente em causa a segurança de um sistema.

Sendo assim, seria de esperar que estes fossem extremamente seguros, no entanto os gestores de pacotes mais comuns têm algumas vulnerabilidades...

Os principais ataques sofridos pelos gestores de pacotes são do tipo: [15]● Replay Attacks● Endless Data Attack● Extraneous Dependencies● Unsatisfiable Dependencies● Provides Everything

Grande parte destes ataques podem ser evitados através da utilização de gestores de pacotes e de repositórios que suportem a assinatura por chaves encriptadas dos pacotes (por exemplo apt e yast), no entanto este tipo de solução não resolve todos os problemas, pois ainda existe muito trabalho por ser feito neste campo.

17

Anexo II – Exemplo concreto de utilização de aptDe seguida dá-se um exemplo concreto de como proceder para adicionar um novo repositório

na distribuição Ubuntu (um exemplo de uma distribuição derivada do Debian) e para instalar um pacote a partir desse repositório através do gestor de pacotes apt.

A título de exemplo, instalemos, pelo método tradicional, a partir do repositório Medibuntu (contém codecs de áudio e vídeo não disponíveis de raiz no sistema por razões comerciais) o pacote w32codecs (permite-nos tocar formatos áudio que não vêm disponíveis por defeito no Ubuntu).

Primeiro fazemos uma cópia de segurança do ficheiro que contêm a lista de repositórios:$ sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup

De seguida adicionamos o repositório do Medibuntu, acrescentando no ficheiro /etc/apt/sources.list o texto (com qualquer editor de texto disponível no sistema, por exemplo vi ou gedit)

“deb http://packages.medibuntu.org/ maverick free non-free”

Agora podemos obter e adicionar a chave de segurança do repositório do medibuntu através do comando:

$ wget --quiet http://packages.medibuntu.org/medibuntu-key.gpg -O - | sudo apt-key add -

Como alterámos a lista de repositórios, há que pedir ao apt para reler a lista:$ sudo apt-get update

Temos tudo pronto para que seja possível instalar qualquer pacote presente no repositório que acabámos de instalar. Instalemos, por exemplo, o pacote w32codecs:

$ sudo apt-get install w32codecs

As novas versões do Ubuntu têm um sistema que permite adicionar um novo repositório e a sua chave digital automaticamente. Vamos então exemplificar como é que, com este sistema, podemos instalar o software de informação geográfica Quantum GIS, presente no repositório ubuntugis:

Adicionemos o repositório e a sua chave simultaneamente:$ sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable

Actualizemos a lista de repositórios e instalemos o pacote correspondente ao programa:$ sudo apt-get update && sudo apt-get install qgis

Com ambas as opções conseguimos, sem grande dificuldade, instalar um pacote a partir de um repositório desconhecido, à partida, para o sistema.