[OpenBSD]

[Índice da FAQ] [Seção 14 - Configuração dos Discos]

15 - O sistema de pacotes e portes do OpenBSD


Conteúdo


15.1 - Introdução

Existem muitos aplicativos de terceiros que alguém talvez queira usar em um sistema OpenBSD. Para fazer com que esse software seja simples de instalar e administrar, e para que ele satisfaça as políticas e objetivos do OpenBSD, o software de terceiros é portado para o OpenBSD. O esforço na portagem pode envolver muitas coisas diferentes. Exemplos: fazer com que o software use o sistema de diretórios padrão do OpenBSD (por exemplo, arquivos de configuração vão para /etc); conformizar com as especificações de bibliotecas compartilhadas do OpenBSD; tornar o software mais seguro, sempre que possível; etc.

O resultado final dos esforços na portagem são os pacotes binários prontos para instalar. O objetivo do sistema de pacotes é manter o registro de quais softwares estão instalados, para que eles possam ser atualizados ou removidos de maneira descomplicada. Dessa forma, arquivos desnecessários não são deixados para trás, e os usuários podem manter os seus sistemas limpos. O sistema de pacotes também assegura que nada seja excluído por acidente, o que faria com que o software parasse de funcionar corretamente. Uma outra vantagem é que os usuários raramente precisam compilar softwares a partir do código fonte, porque os pacotes já estão compilados, disponíveis e prontos para serem usados em um sistema OpenBSD. Em questão de minutos, uma grande quantidade de pacotes pode ser baixada e instalada, com tudo no lugar certo.

A coleção de pacotes e portes NÃO recebe a mesma auditoria de segurança que é feita no sistema base do OpenBSD. Embora nós tentemos manter a qualidade da coleção de pacotes alta, simplesmente não temos recursos humanos suficientes para garantir o mesmo nível de poder e segurança.

15.2 - Gerenciamento de Pacotes

15.2.1 - Como que funciona?

Pacotes são binários pré-compilados de alguns dos softwares de terceiros mais usados. Os pacotes podem ser gerenciados facilmente com a ajuda de vários utilitários, também conhecidos como ferramentas pkg*:

Para funcionar corretamente, um aplicativo X pode requerir que os aplicativos Y e Z sejam instalados. O aplicativo X é dito ser dependente desses outros aplicativos, e é por isso que Y e Z são chamados de dependências de X. Pode acontecer de Y requerir os aplicativos P e Q, e Z pode requerir o aplicativo R para funcionar corretamente. Dessa forma, uma árvore de dependências é formada.

Pacotes aparentam ser simples arquivos .tgz. E, basicamente, é o que eles são, mas existe uma diferença crucial: eles contêm informação de empacotamento. Essa informação é usada pelo pkg_add(1) para diversos propósitos:

15.2.2 - Como tornar as coisas simples: PKG_PATH

Você pode tornar as coisas realmente simples através do uso da variável de ambiente PKG_PATH. Apenas aponte-a para a sua localização favorita e o pkg_add(1) busca automaticamente no lugar apontado os pacotes que você especificar, e também baixa e instala automaticamente as dependências necessárias do pacote.

Uma lista de localizações possíveis para baixar pacotes é fornecida na seção seguinte.

Exemplo 1: baixando do seu CD-ROM, assumindo que você o montou em /mnt/cdrom:

$ export PKG_PATH=/mnt/cdrom/4.7/packages/`machine -a`/

Exemplo 2: baixando de um espelho FTP próximo:

$ export PKG_PATH=ftp://seu.espelho.ftp/pub/OpenBSD/4.7/packages/`machine -a`/

Normalmente, é uma boa ideia adicionar uma linha similar a dos exemplos acima no seu ~/.profile. Do mesmo modo que a clássica variável PATH, você pode especificar múltiplas localizações, separando-as com dois-pontos. Em versões anteriores ao OpenBSD 4.4, todo caminho na variável PKG_PATH PRECISA terminar em uma barra (/). Dessa forma, o pkg_add(1) pode dividir corretamente o caminho, mesmo se ele tenha esquemas de URL contendo dois-pontos. Se a primeira entrada em PKG_PATH falha, a próxima é tentada, e assim vai, até que o pacote seja encontrado. Se todas as entradas falham, um erro é produzido.

Note o uso do comando machine(1) nas linhas de comando acima. Isso substitui automaticamente a sua "arquitetura de aplicação" do OpenBSD instalado, que normalmente é, mas nem sempre, o nome da sua plataforma. Se você está usando snapshots, você deve trocar "4.7" por "snapshots".

15.2.3 - Buscas de pacotes

Uma grande coleção de pacotes pré-compilados está disponível para as arquiteturas mais comuns. Procure o seu pacote em um dos seguintes lugares:

Se você possui a árvore de portes no seu sistema, você pode buscar rapidamente o pacote que você está procurando como explicado em Pesquisas na árvore de portes.

Você vai notar que certos pacotes estão disponíveis em variedades diferentes, chamados formalmente de sabores ("flavors"). Outros são partes do mesmo aplicativo, mas que podem ser instalados separadamente. Estes são chamados subpacotes. Isso é abordado em mais detalhes na seção Utilização dos sabores ("flavors") e dos subpacotes ("subpackages"), mas é simples dizer que um sabor significa que eles são configurados com diferentes conjuntos de opções. Atualmente, muitos pacotes possuem sabores, por exemplo: suporte a banco de dados, suporte para sistemas sem o X, ou adições de rede, como SSL e IPv6. Todo sabor de um pacote contém um sufixo diferente no seu nome de pacote. Para informações detalhadas sobre nomes de pacotes, consulte packages-specs(7).

Nota: Nem todos os possíveis pacotes estão disponíveis nos servidores FTP! Alguns aplicativos simplesmente não funcionam em todas as arquiteturas. Alguns aplicativos não podem ser distribuídos via FTP (ou CD-ROM) devido à problemas de licença. Também podem existir muitas combinações possíveis de sabores de um porte, e o projeto OpenBSD simplesmente não possui recursos para compilar todos eles. Se você precisa de uma combinação que não está disponível, você vai ter que compilar o porte a partir do código fonte. Para mais informações sobre como fazer isso, leia Utilização dos sabores ("flavors") e dos subpacotes ("subpackages"), na seção Portes deste documento.

15.2.4 - Instalação de novos pacotes

Para instalar pacotes, o utilitário pkg_add(1) é usado. Se você tornou as coisas simples, definindo a variável de ambiente PKG_PATH, você pode apenas chamar o pkg_add(1) com o nome do pacote, como no seguinte exemplo básico.
$ sudo pkg_add -v screen-4.0.3p1
parsing screen-4.0.3p1
installed /etc/screenrc from /usr/local/share/examples/screen/screenrc | 71%
screen-4.0.3p1: complete

Nesse exemplo, o sinalizador -v foi usado para se obter uma saída mais detalhada. Esse sinalizador não é necessário, mas ele é útil para depuração, e foi usado aqui para uma visão mais profunda sobre o que o pkg_add(1) está fazendo. Note a mensagem mencionando /etc/screenrc. Especificar múltiplos sinalizadores -v produz uma saída ainda mais detalhada.

Como usar o pkg_add(1) em modo interativo

Desde o OpenBSD 3.9, o pkg_add(1) possui um modo interativo que é ativado através do sinalizador -i, fazendo com que ele faça questões quando não pode tomar decisões sozinho. Por exemplo, se você não sabe o número de versão de um pacote, você pode tentar algo como:
$ sudo pkg_add -i screen
Ambiguous: screen could be screen-4.0.3p1 screen-4.0.3p1-shm screen-4.0.3p1-static
Choose one package
         0: <None>
         1: screen-4.0.3p1
         2: screen-4.0.3p1-shm
         3: screen-4.0.3p1-static
Your choice: 1
screen-4.0.3p1: complete

Para alguns pacotes, algumas informações adicionais importantes serão mostradas, informações estas sobre a configuração ou uso do aplicativo em um sistema OpenBSD. Sendo que isso é importante, será mostrado mesmo se você usar ou não o sinalizador -v. Considere o seguinte exemplo:

$ sudo pkg_add ghostscript-fonts-8.11
ghostscript-fonts-8.11: complete
You may wish to update your font path for /usr/local/share/ghostscript/fonts
--- ghostscript-fonts-8.11 -------------------
To install these fonts for X11, just make sure that the fontpath
lists the 75dpi or 100dpi bitmap fonts before the ghostscript fonts,
and make sure you have the string ":unscaled" appended to the bitmap
font's fontpath. This way, the bitmap fonts will be used if they
match, and the Type 1 versions will be used if the font needs to be
scaled. Below is the relevant section from a typical xorg.conf file.

   FontPath   "/usr/X11R6/lib/X11/fonts/misc/"
   FontPath   "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
   FontPath   "/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
   FontPath   "/usr/local/lib/X11/fonts/ghostscript/"
   FontPath   "/usr/X11R6/lib/X11/fonts/Type1/"

Vamos continuar agora com um exemplo de pacote que possui dependências:

$ sudo pkg_add -v tin-1.8.2p0
parsing tin-1.8.2p0
Dependencies for tin-1.6.2 resolve to: gettext-0.14.6, libutf8-0.8, pcre-6.4p1, libiconv-1.9.2p3 (todo: libiconv-1.9.2p3,gettext-0.14.6,pcre-6.4p1,libutf8-0.8)
tin-1.8.2p0:parsing libiconv-1.9.2p3
tin-1.8.2p0:libiconv-1.9.2p3: complete
tin-1.8.2p0:parsing gettext-0.14.6
Dependencies for gettext-0.14.6 resolve to: expat-2.0.0, libiconv-1.9.2p3 (todo: expat-2.0.0)
tin-1.8.2p0:parsing expat-2.0.0
tin-1.8.2p0:expat-2.0.0: complete
tin-1.8.2p0:gettext-0.14.6: complete
tin-1.8.2p0:parsing pcre-6.4p1
tin-1.8.2p0:pcre-6.4p1: complete
tin-1.8.2p0:parsing libutf8-0.8
tin-1.8.2p0:libutf8-0.8: complete
tin-1.8.2p0: complete
Adicionamos novamente o sinalizador -v para ver o que está acontecendo. Após investigar a informação de empacotamento, as dependências são encontradas e instaladas em primeiro lugar. Perto do meio da saída você pode ver o pacote gettext sendo instalado, e este depende da libiconv. Antes de instalar o gettext, sua informação de empacotamento é examinada e é verificado se libiconv já está instalada.

É possível especificar múltiplos nomes de pacote em uma linha, e eles são instalados um por um, junto com as possíveis dependências.

Se, por alguma razão, você decide não usar PKG_PATH, também é possível especificar na linha de comando a localização absoluta de um pacote. Essa localização absoluta pode ser um caminho local, ou uma URL referenciando localizações FTP, HTTP, ou SCP. Vamos considerar a instalação via FTP no exemplo seguinte:

$ sudo pkg_add ftp://ftp.openbsd.org/pub/OpenBSD/4.7/packages/`machine -a`/screen-4.0.3p1.tgz
screen-4.0.3p1: complete

Nesse exemplo, o sinalizador -v não foi usado, então somente as mensagens necessárias são mostradas. Note que o nome de arquivo completo foi digitado, incluindo o sufixo .tgz. Você pode evitar esse sufixo, como nos exemplos anteriores, pois ele é completado automaticamente pelo pkg_add(1).

Nota: Nem todas as arquiteturas possuem os mesmos pacotes disponíveis. Alguns portes não funcionam em certas arquiteturas, e o desempenho limita o número de pacotes que podem ser compilados em outras.

Se você está instalando um pacote que você já tinha instalado antes (ou uma versão anterior dele) e depois removeu, por motivos de segurança o pkg_add(1) não sobrescreve os arquivos de configuração que foram modificados. No lugar, ele informa a você sobre isso (somente ao usar o sinalizador -v, entretanto):

$ sudo pkg_add -v screen-4.0.3p1
parsing screen-4.0.3p1
The existing file /etc/screenrc has NOT been changed**                 | 71%
It does NOT match the sample file /usr/local/share/examples/screen/screenrc
You may wish to update it manually
screen-4.0.3p1: complete
Algumas vezes você pode encontrar um erro igual ao do exemplo a seguir:
$ sudo pkg_add xv-3.10ap4
xv-3.10ap4:jpeg-6bp3: complete
xv-3.10ap4:png-1.2.14p0: complete
xv-3.10ap4:tiff-3.8.2p0: complete
Can't install xv-3.10ap4: lib not found X11.9.0
Even by looking in the dependency tree:
        tiff-3.8.2p0, jpeg-6bp3, png-1.2.14p0
Maybe it's in a dependent package, but not tagged with @lib ?
(check with pkg_info -K -L)
If you are still running 3.6 packages, update them.
Esse é o pkg_add(1) instalando belamente as dependências, quando de repente ele interrompe a instalação do xv. Essa é outra precaução de segurança que está disponível desde o OpenBSD 3.7. A informação de empacotamento, contida no pacote, inclui informação sobre bibliotecas compartilhadas que o pacote espera que estejam instaladas, bibliotecas do sistema, como também as bibliotecas de terceiros. Se uma das bibliotecas requeridas não pode ser encontrada, o pacote não é instalado porque ele, de qualquer forma, não funcionaria.

Para resolver esse tipo de conflito, você precisa encontrar o que instalar para ter as bibliotecas requeridas no seu sistema. Existem diversas coisas para verificar:

15.2.5 - Listagem de pacotes instalados

Você pode ver uma lista dos pacotes instalados usando o utilitário pkg_info(1).
$ pkg_info
aterm-0.4.2p1       color vt102 terminal emulator with transparency support
bzip2-1.0.4         block-sorting file compressor, unencumbered
expat-2.0.0         XML 1.0 parser written in C
fluxbox-0.9.15.1p0  window manager based on the original Blackbox code
gettext-0.14.6      GNU gettext
imlib2-1.3.0        image manipulation library
jpeg-6bp3           IJG's JPEG compression utilities
libiconv-1.9.2p3    character set conversion library
libltdl-1.5.22p1    GNU libtool system independent dlopen wrapper
libungif-4.1.4p0    tools and library routines for working with GIF images
libutf8-0.8         provides UTF-8 locale support
mutt-1.4.2.2i       tty-based e-mail client
pcre-6.4p1          perl-compatible regular expression library
png-1.2.14p0        library for manipulating PNG images
screen-4.0.3p1      multi-screen window manager
tcsh-6.14.00p1      extended C-shell with many useful features
tiff-3.8.2p0        tools and library routines for working with TIFF images
tin-1.8.2p0         threaded NNTP and spool based UseNet newsreader

Ao passar um nome de pacote instalado (ou a localização de um pacote para ser instalado), o pkg_info(1) mostra informações detalhadas a respeito daquele pacote.

15.2.6 - Atualização de pacotes instalados

Digamos que você tinha instalado uma versão antiga do unzip antes de atualizar do OpenBSD 4.6 para o 4.7. Agora você pode atualizar facilmente para o novo pacote do 4.7:
$ sudo pkg_add -u unzip
unzip-5.52p0 (extracting): complete
unzip-5.52 (deleting): complete
unzip-5.52p0 (installing): complete
Clean shared items: complete

Quando um pacote tem dependências, elas também são examinadas à procura de atualizações. Ao executar o pkg_add(1) com o sinalizador -u e nenhum nome de pacote, todos os pacotes instalados são atualizados.

Nota: O comutador -u usa a variável de ambiente PKG_PATH. Se ela não está definida, o pkg_add(1) não é capaz de procurar atualizações.

A partir do OpenBSD 4.2, possuir múltiplas entradas em PKG_PATH não significa que todas as entradas serão usadas em operações de atualização. Em vez disso, o pkg_add(1) vai parar no primeiro caminho com candidatos adequados.

Se você possui um arquivo de configuração pertencente a uma versão antiga, e que foi modificado, ele será mantido, por padrão. Você pode, no entanto, trocá-lo pelo arquivo de configuração padrão da nova versão, chamando o pkg_add(1) com o sinalizador -c.

15.2.7 - Remoção de pacotes instalados

Para remover um pacote, pegue o nome próprio do pacote, como é mostrado pelo pkg_info(1) (veja Listagem de pacotes instalados), e use o pkg_delete(1) para remover o pacote. No exemplo a seguir, o pacote screen é removido. Note que, em algumas ocasiões, existem instruções de itens extras que precisam ser removidos, que o pkg_delete(1) não remove para você. Como no utilitário pkg_add(1), você pode usar o sinalizador -v para obter uma saída mais detalhada.

$ sudo pkg_delete screen
screen-4.0.3p1: complete
Clean shared items: complete

Nota: Na maioria das vezes, não é necessário especificar os números de versão e sabores com o nome do pacote, já que o pkg_delete(1) normalmente é capaz de encontrar o nome completo sozinho. Você precisa especificar o nome completo do pacote (no exemplo, que é screen-4.0.3p1) somente se alguma ambiguidade é possível, devido a múltiplos pacotes instalados com o nome especificado. Nesse caso, o pkg_delete(1) não sabe qual pacote excluir.

Por questões de segurança, o pkg_delete(1) não remove os arquivos de configuração se eles foram modificados. No lugar, ele informa você sobre isso:

$ sudo pkg_delete screen
screen-4.0.3p1: complete
Clean shared items: complete 
--- screen-4.0.3p1 -------------------
You should also remove /etc/screenrc (which was modified)

Se você prefere que esses arquivos de configuração sejam removidos automaticamente, você pode fazer isso usando o sinalizador -c.

15.2.8 - Instalação ou remoção incompleta de pacote

Em alguns casos raros, você pode se deparar com um pacote que não foi adicionado ou excluído completamente por causa de conflitos com outros arquivos. A instalação incompleta é normalmente marcada com um "partial-" no começo do nome do pacote. Por exemplo, isso pode acontecer quando você aperta CTRL+C durante a instalação:
$ sudo pkg_add screen-4.0.3p1
screen-4.0.3p1: complete                                                      7%
Adjusting md5 for /usr/local/info/screen.info-3 from 49fb3fe1cc3a3b0057518459811b6dac to 3b9c7811244fb9f8d83bb27d3a0f60d8
/usr/sbin/pkg_add: Installation of screen-4.0.3p1 failed , partial installation recorded as partial-screen-4.0.3p1

Sempre é uma boa ideia remover os pacotes parciais do seu sistema, e consertar problemas potenciais que levam a essa falha. Frequentemente, essa é uma indicação de que você não possui um sistema limpo, com tudo instalado a partir de pacotes, e possivelmente possui pacotes misturados com outros softwares instalados a partir do código fonte.

15.3 - Utilização do portes

Como foi mencionado na introdução, pacotes são compilados a partir da árvore de portes. Nesta seção vamos explicar como a árvore de portes funciona, quando você deve e como você pode utilizá-la.

NOTA IMPORTANTE: A árvore de portes é pensada para usuários avançados. Todos são incentivados a usar os pacotes de binários pré-compilados. NÃO faça perguntas de iniciante, do tipo "Como eu faço para a árvore de portes funcionar?", nas listas de discussão. Se você tem dúvidas quanto à árvore de portes, é assumido que você leu as páginas de manual e esta FAQ, e que você é capaz de utilizá-la.

15.3.1 - Como que funciona?

A árvore de portes, um conceito originalmente emprestado do FreeBSD, é um conjunto de Makefiles, um para cada aplicativo de terceiro, que controlam

Além do arquivo Makefile, cada porte também contém, no mínimo, o seguinte:

Toda essa informação é mantida em uma hierarquia de diretórios em /usr/ports. Essa hierarquia contém três subdiretórios especiais:

Os outros subdiretórios formam diferentes categorias de aplicativos, que contêm os subdiretórios dos verdadeiros portes. Portes complexos podem ser organizados em um nível ainda mais profundo; por exemplo, uma parte central e um conjunto de extensões, ou uma versão estável e uma versão snapshot de um aplicativo. Cada diretório de porte precisa conter um subdiretório pkg/, contendo a(s) lista(s) de empacotamento e o(s) arquivo(s) de descrição. Também podem existir os subdiretórios patches/ e files/, para as correções de código fonte e arquivos adicionais, respectivamente.

Quando um usuário executa o make(1) em subdiretório de um porte específico, o sistema vai caminhar de modo recursivo a árvore de dependências, verificar se as dependências exigidas estão instaladas, compilar e instalar as dependências que estão faltando, e então continuar a compilação do porte desejado. Toda a parte de compilação acontece dentro de um diretório de trabalho que o porte cria. Normalmente, ele fica dentro de ${WRKOBJDIR}, que possui o valor padrão /usr/ports/pobj, mas você pode sobrescrever isso (veja Configuração do sistema de portes). Se WRKOBJDIR foi explicitamente indefinido, um subdiretório do diretório principal do porte (nome do pacote prefixado por "w-") é utilizado no lugar.

Nota: Portes nunca são instalados diretamente no seu sistema! Eles usam um diretório de instalação falso. Tudo que é instalado lá é então unido em um pacote (que é armazenado no subdiretório packages/ da árvore de portes, como mencionado anteriormente). A instalação de um porte significa realmente: criar um pacote e então instalar aquele pacote!

Mais informação sobre o sistema de portes pode ser encontrada nestas páginas de manual:

15.3.2 - Download da árvore de portes

Antes de continuar, você precisa ler a seção sobre NÃO misturar sabores diferentes do seu sistema OpenBSD e da árvore de portes. Após decidir qual sabor da árvore de portes você quer, você pode obter a árvore de portes a partir de diferentes locais. A tabela a seguir mostra uma visão geral de onde você pode encontrar os sabores diferentes, e em qual formato. Um 'x' marca a disponibilidade e um '-' significa que não está disponível através daquele local.

Local Formato Sabor
-release -stable snapshots -current
CD-ROM .tar.gz x - - -
Espelhos FTP .tar.gz x - x -
AnonCVS cvs checkout x x - x

No CD-ROM e nos espelhos FTP, procure um arquivo chamado ports.tar.gz. Você precisa descompactar esse arquivo no diretório /usr, o que cria /usr/ports e todos os diretórios dentro dele. Por exemplo:

$ cd /tmp
$ ftp ftp://ftp.openbsd.org/pub/OpenBSD/4.7/ports.tar.gz
$ cd /usr
$ sudo tar xzf /tmp/ports.tar.gz

As snapshots disponíveis nos espelhos FTP são geradas diariamente a partir de uma árvore de portes -current. Você encontra as snapshots no diretório pub/OpenBSD/snapshots/. Se você está usando uma snapshot da árvore de portes, você deve ter instalado a snapshot correspondente do OpenBSD. Mantenha sua árvore de portes e seu sistema OpenBSD em sincronia!

Para mais informações sobre como obter a árvore de portes via AnonCVS, leia a página AnonCVS, que contém uma lista de servidores disponíveis e vários exemplos.

15.3.3 - Configuração do sistema de portes

NOTA: Esta seção introduz algumas configurações globais adicionais para a compilação de aplicativos a partir do portes. Você pode pular esta seção, mas você terá que executar como root muitas das instruções make(1) dos exemplos.

O projeto OpenBSD não possui recursos para revisar completamente o código fonte de todos os softwares na árvore de portes, mas você pode configurar o sistema de portes para tomar algumas medidas de segurança. A infraestrutura do portes é capaz de realizar toda a compilação como um usuário normal, e realizar como usuário root somente aquelas etapas que necessitam dos privilégios de super usuário. Exemplos disso são os alvos fake e install do make. No entanto, pelo fato de que privilégios do root sejam sempre necessários em algum ponto, o sistema de portes não vai salvá-lo quando você decidir compilar um aplicativo malicioso.

É possível usar a árvore de portes em modo "apenas para leitura" separando os diretórios que são escritos durante a compilação do porte:

Por exemplo, você pode adicionar as seguintes linhas no /etc/mk.conf
WRKOBJDIR=/usr/obj/ports
DISTDIR=/usr/distfiles
PACKAGE_REPOSITORY=/usr/packages
Se desejado, você pode também alterar a propriedade desses diretórios para o seu nome de usuário e grupo local, assim o sistema de portes pode criar os diretórios de trabalho como um usuário normal.

15.3.4 - Pesquisas na árvore de portes

Uma vez que a árvore de portes está instalada no seu sistema, a tarefa de pesquisar software torna-se muito simples. Simplesmente use make search key="palavra-chave", como mostrado no exemplo seguinte.
$ cd /usr/ports
$ make search key=rsnapshot
Port:   rsnapshot-1.3.1p0
Path:   net/rsnapshot
Info:   remote filesystem snapshot utility
Maint:  Antoine Jacoutot <ajacoutot@openbsd.org>
Index:  net sysutils
L-deps:
B-deps: :net/rsync
R-deps: :devel/p5-Lchown :net/rsync
Archs:  any
O resultado da busca mostra uma visão geral de cada aplicativo encontrado: o nome do porte, o caminho para o porte, uma descrição de uma linha, o mantenedor do porte, palavras-chave relacionadas ao porte, dependências de biblioteca/compilação/execução, e arquiteturas onde é de conhecimento que o porte funciona.

Esse mecanismo, no entanto, é muito básico: ele apenas executa o awk(1) no arquivo de índice do portes. A partir do OpenBSD 4.0, um novo porte chamado "sqlports" foi criado, permitindo pesquisas precisas usando SQL. Ele é um banco de dados SQLite, mas basicamente qualquer formato de banco de dados pode ser criado usando a infraestrutura do portes. O porte sqlports inclui o script usado para gerar o banco de dados, que pode ser usado como base para gerar bancos de dados em formatos diferentes.

Para começar a utilizá-lo, use o pkg_add(1) para adicionar o pacote sqlports, neste caso o pacote sqlite3. Uma sessão de exemplo se parece com esta:

$ sqlite3 /usr/local/share/sqlports
SQLite version 3.3.12
Enter ".help" for instructions
sqlite> SELECT FULLPKGNAME,COMMENT FROM Ports WHERE COMMENT LIKE '%statistics%'; 
Guppi-0.40.3p1|GNOME-based plot program with statistics capabilities
mailgraph-1.12|a RRDtool frontend for Postfix statistics
R-2.4.1|clone of S, a powerful math/statistics/graphics language
py-probstat-0.912p0|probability and statistics utilities for Python
darkstat-3.0.540p1|network statistics gatherer with graphs
pfstat-2.2p0|packet filter statistics visualization
tcpstat-1.4|report network interface statistics
wmwave-0.4p2|Window Maker dockapp to display wavelan statistics
diffstat-1.43p0|accumulates and displays statistics from a diff file
sqlite>
O exemplo acima é, ainda, uma pesquisa muito básica. Com o SQL, qualquer coisa pode ser pesquisada, incluindo dependências, opções de configuração, bibliotecas compartilhadas, etc.

15.3.5 - Instalação rápida: um exemplo simples

Com a intenção de tornar as coisas claras, vamos considerar um exemplo simples: rsnapshot. Esse aplicativo tem uma dependência: rsync.
$ cd /usr/ports/net/rsnapshot
$ make install
===>  Checking files for rsnapshot-1.2.9
>> rsnapshot-1.2.9.tar.gz doesn't seem to exist on this system.
>> Fetch http://www.rsnapshot.org/downloads/rsnapshot-1.2.9.tar.gz.
100% |**************************************************|   173 KB    00:02
>> Size matches for /usr/ports/distfiles/rsnapshot-1.2.9.tar.gz
>> Checksum OK for rsnapshot-1.2.9.tar.gz. (sha1)
===>  rsnapshot-1.2.9 depends on: rsync-2.6.9 - not found
===>  Verifying install for rsync-2.6.9 in net/rsync
===>  Checking files for rsync-2.6.9
>> rsync-2.6.9.tar.gz doesn't seem to exist on this system.
>> Fetch ftp://ftp.samba.org/pub/rsync/old-versions/rsync-2.6.9.tar.gz.
100% |**************************************************|   792 KB    00:31
>> Size matches for /usr/ports/distfiles/rsync-2.6.9.tar.gz
>> Checksum OK for rsync-2.6.9.tar.gz. (sha1)
===>  Verifying specs:  c
===>  found c.40.3
===>  Extracting for rsync-2.6.9
===>  Patching for rsync-2.6.9
===>  Configuring for rsync-2.6.9
  [... recorte ...]
===>  Building for rsync-2.6.9
  [... recorte ...]
===>  Faking installation for rsync-2.6.9
  [... recorte ...]
===>  Building package for rsync-2.6.9
Link to /usr/ports/packages/i386/ftp/rsync-2.6.9.tgz
Link to /usr/ports/packages/i386/cdrom/rsync-2.6.9.tgz
===>  Installing rsync-2.6.9 from /usr/ports/packages/i386/all/rsync-2.6.9.tgz
rsync-2.6.9: complete
===> Returning to build of rsnapshot-1.2.9
===>  rsnapshot-1.2.9 depends on: rsync-2.6.9 - found
===>  Extracting for rsnapshot-1.2.9
===>  Patching for rsnapshot-1.2.9
===>  Configuring for rsnapshot-1.2.9
  [... recorte ...]
===>  Building for rsnapshot-1.2.9
  [... recorte ...]
===>  Faking installation for rsnapshot-1.2.9
  [... recorte ...]
===>  Building package for rsnapshot-1.2.9
Link to /usr/ports/packages/i386/ftp/rsnapshot-1.2.9.tgz
Link to /usr/ports/packages/i386/cdrom/rsnapshot-1.2.9.tgz
===>  rsnapshot-1.2.9 depends on: rsync-2.6.9 - found
===>  Installing rsnapshot-1.2.9 from /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz
rsnapshot-1.2.9: complete

Como você pode ver, o sistema de portes está fazendo muitas coisas automaticamente. Ele vai baixar, extrair e corrigir (aplicar "patches") o código fonte, configurar e construir (compilar) o código fonte, instalar os arquivos no diretório falso, criar um pacote (correspondendo à lista de empacotamento) e instalar esse pacote no seu sistema (dentro de /usr/local/, usualmente). E ele faz isso recursivamente em todas as dependências do porte. Note as linhas "===> Verifying install for ..." e "===> Returning to build of ..." na saída acima, indicando a caminhada pela árvore de dependências.

Se uma versão anterior do aplicativo que você quer instalar já está instalada no seu sistema, você pode usar make update em vez make install. Isso chama o pkg_add(1) com o sinalizador -r.

Nota: Aplicativos muito grandes necessitam de uma grande quantidade de recursos do sistema para compilar. Bons exemplos são os compiladores, como o GCC 4.0, ou o Kit de Desenvolvimento de Software Java 2. Se você obtém erros do tipo "out of memory" durante a compilação de um porte, isso normalmente tem uma das seguintes causas:

15.3.6 - Limpeza após uma compilação

Você provavelmente quer limpar o diretório de trabalho padrão do porte após ter compilado e instalado o pacote.
$ make clean
===>  Cleaning for rsnapshot-1.2.9
Adicionalmente, você também pode limpar os diretórios de trabalho de todas as dependências do porte, com este alvo make:
$ make clean=depends
===>  Cleaning for rsync-2.6.9
===>  Cleaning for rsnapshot-1.2.9
Se você deseja remover o conjunto de arquivos de distribuição do porte, você pode usar
$ make clean=dist
===>  Cleaning for rsnapshot-1.2.9
===>  Dist cleaning for rsnapshot-1.2.9
Caso você tenha compilado múltiplos sabores do mesmo porte, você pode limpar de uma vez só os diretórios de trabalho de todos os sabores usando
$ make clean=flavors
Através da definição de uma variável especial, você pode também limpar as coisas enquanto elas são compiladas. Diretórios de trabalho são automaticamente limpados após os pacotes serem criados:
$ make package BULK=Yes

15.3.7 - Desinstalação de um pacote do porte

É muito simples desinstalar um porte:
$ make uninstall
===> Deinstalling for rsnapshot-1.2.9
rsnapshot-1.2.9: complete
Clean shared items: complete
Isso chama o pkg_delete(1) para remover o pacote correspondente do seu sistema. Se desejado, você também pode desinstalar e reinstalar um pacote de porte usando
$ make reinstall
===>  Cleaning for rsnapshot-1.2.9
/usr/sbin/pkg_delete rsnapshot-1.2.9
rsnapshot-1.2.9: complete
Clean shared items: complete
===>  Installing rsnapshot-1.2.9 from /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz
rsnapshot-1.2.9: complete
Se você quer se livrar dos pacotes que criou, você pode fazer o seguinte:
$ make clean=packages
===>  Cleaning for rsnapshot-1.2.9
rm -f /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz

15.3.8 - Utilização dos sabores ("flavors") e dos subpacotes ("subpackages")

Por favor, leia a página de manual ports(7), que fornece uma visão geral deste tópico. Existem dois mecanismos para controlar o empacotamento do software de acordo com diferentes necessidades.

O primeiro mecanismo é chamado sabores ("flavors"). Um sabor normalmente indica um certo conjunto de opções de compilação. Por exemplo, alguns aplicativos possuem um sabor "no_x11", que pode ser usado em sistemas sem o X. Alguns shells possuem um sabor "static", que compila uma versão ligada estaticamente. Existem alguns portes que possuem diferentes sabores para a compilação com diferentes kits de ferramentas gráficas. Outros exemplos: suporte para diferentes formatos de banco de dados, diferentes opções de rede (SSL, IPv6, ...), diferentes tamanhos de papel, etc.

Sumário: Na maioria das vezes, você usará os sabores quando um pacote não está disponível para o sabor que você está procurando. Nesse caso, você terá que especificar o sabor desejado e compilar o porte você mesmo.

A maioria dos sabores de um porte possui seu próprio diretório de trabalho durante a compilação, e cada sabor será empacotado com um nome de pacote correspondente para evitar qualquer confusão. Para ver os diferentes sabores de um certo porte, você deve ir para o seu subdiretório e digitar

$ make show=FLAVORS
Você deve também olhar os arquivos DESCR do porte, já que é esperado que eles expliquem os sabores disponíveis.

O segundo mecanismo é chamado subpacotes ("subpackages"). Um desenvolvedor de portes pode decidir criar subpacotes para diferentes partes do mesmo aplicativo se elas podem ser separadas logicamente. Você frequentemente verá subpacotes para a parte cliente e para a parte servidor de um programa. Algumas vezes, uma documentação importante é empacotada em um subpacote separado porque ela ocupa muito espaço em disco. Funcionalidades extras que adicionam uma grande quantidade de dependências são empacotadas separadamente. O desenvolvedor de portes também deve decidir qual subpacote é considerado o principal, para ser instalado por padrão. Outros exemplos são: a suíte de testes importantes que é fornecida junto com o software, módulos separados com suporte para coisas diversas, etc.

Sumário: Alguns portes são divididos em vários pacotes. make install instala somente o subpacote principal.

Para listar os diferentes pacotes criados por um porte, use

$ make show=PACKAGES

make install instala somente o subpacote principal. Para instalar todos eles, use

$ make install-all

Para listar os diferentes subpacotes disponíveis para um porte, use

$ make show=MULTI_PACKAGES
É possível selecionar qual(is) subpacote(s) instalar a partir da árvore de portes. Depois de alguns testes, este procedimento chama o pkg_add(1) para instalar o(s) subpacote(s) desejado(s).
$ env SUBPACKAGE="-server" make install

Nota: O mecanismo de subpacotes somente controla pacotes, ele não modifica nenhuma das opções de configuração antes de compilar o porte. Para essa finalidade, você deve usar os sabores.

15.4 - FAQ

15.4.1 - Estou recebendo todo tipo de erros malucos. Eu não sei como fazer o portes funcionar.

É provável que você esteja usando um sistema e uma árvore de portes que não estão em sincronia.

Como assim?

Outra falha comum é a falta da instalação do X11. Mesmo se o porte que você tenta compilar não tem uma dependência direta do X11, um subpacote dele, ou suas dependências, pode requerir cabeçalhos e bibliotecas do X11. Compilar portes em sistemas sem o X11 não é uma tarefa suportada; se você insiste em fazer isso, você está sozinho nessa. Para muitos portes, no entanto, existem pacotes com o sabor "no_x11", que você pode instalar sem precisar do X11 no seu sistema.

15.4.2 - A última versão do meu software favorito/preferido não está disponível!

Se você está usando uma versão release ou stable do OpenBSD, você não encontrará nenhuma atualização dos pacotes até a próxima release, a menos que problemas de segurança ocorram e justifiquem uma atualização do porte no ramo -stable e do pacote correspondente.

AVISO: NÃO misture versões do Portes e do OpenBSD!

Fazendo isso, mais cedo ou mais tarde (provavelmente muito cedo, de fato) você terá dores de cabeça tentando resolver todos os tipos de erros!

Mas ei, estou usando tudo -current aqui!

A coleção de portes é um projeto voluntário. Algumas vezes o projeto simplesmente não possui recursos de desenvolvimento para manter tudo em dia. Os desenvolvedores se preocupam com aquilo que eles consideram interessante e podem testar em seus ambientes. Suas doações podem fazer diferença nos testes em mais plataformas.

Certos portes podem estar mais antigos que as versões principais por causa disso. A coleção de portes pode ter uma versão de um programa de Janeiro, enquanto uma nova versão do programa foi lançada por seus desenvolvedores em Maio, três meses depois. Frequentemente, essa é uma decisão consciente; a nova versão pode ter problemas no OpenBSD que o mantenedor está tentando resolver, ou a nova versão do aplicativo está mais ruim que a antiga versão: o OpenBSD pode ter objetivos diferentes daqueles dos desenvolvedores principais nos outros projetos, que algumas vezes resulta em características e escolhas de projeto e implementação que são indesejáveis no ponto de vista dos desenvolvedores do OpenBSD. A atualização pode ser adiada se a nova versão não é considerada uma atualização crítica.

Se você realmente precisa de uma nova versão de um porte, você deve pedir ao mantenedor do porte para atualizá-lo (veja abaixo como descobrir quem é o mantenedor). Se você pode ajudar com isso, melhor ainda.

15.4.3 - Por que não existe um pacote do meu software favorito/preferido?

Existem diversas razões possíveis para isso:

15.4.4 - Por que não existe um porte do meu software favorito/preferido?

A coleção de portes é um projeto voluntário. O desenvolvimento ativo de portes é feito no tempo livre de um número limitado de pessoas. Usualmente, essas pessoas fazem novos portes somente para software que usam diretamente ou estão interessadas.

Você pode ajudar. Considere a possibilidade de criar seu próprio porte. Existe alguma documentação disponível sobre isso: o Handbook do Desenvolvedor de Portes do OpenBSD. Leia e leia novamente; especialmente a parte sobre manter o seu porte. Então tente fazer um novo porte, e teste-o cuidadosamente, passo por passo. Se ele finalmente funcionar perfeitamente para você, envie-o para a lista de discussão do portes, em ports@openbsd.org. As chances são grandes de que você receba um retorno e testes de outras pessoas. Se a fase de testes é bem-sucedida, seu porte será considerado a se tornar parte da árvore de portes.

15.4.5 - Por que meu software favorito/preferido não faz parte do sistema base?

O OpenBSD é pensado para ser um pequeno e independente sistema operacional do tipo Unix, e nós devemos traçar uma linha quanto a que é incluído. Geralmente, para um aplicativo ser incluído no sistema base:

Mais respostas para essa pergunta também são encontradas na FAQ 1.

15.4.6 - O que devo utilizar: pacotes ou portes?

Geralmente, é altamente aconselhado que você use pacotes em vez de compilar um aplicativo a partir do portes. A equipe do portes do OpenBSD considera os pacotes como o objetivo do trabalho de portagem, não os portes em si.

Compilar um aplicativo complexo a partir do código fonte não é trivial. Não é somente o aplicativo que precisa ser compilado, mas as ferramentas usadas para compilá-lo também precisam ser compiladas. Infelizmente, o OpenBSD, as ferramentas e o aplicativo estão todos envolvidos e, frequentemente, é um desafio fazer todas essas partes funcionarem juntas. Uma vez que tudo está funcionando, uma modificação no dia seguinte, em alguma das partes, pode fazer tudo parar de funcionar. A cada seis meses, quando uma nova release do OpenBSD é criada, um esforço é feito para testar a compilação de cada porte em cada plataforma, mas durante o ciclo de desenvolvimento é comum que alguns portes não estejam funcionando.

Em adição à tarefa de ter todas as partes trabalhando juntas, existe também a questão de tempo e recursos necessários para compilar alguns aplicativos a partir do código fonte. Um exemplo comum é o CVSup, uma ferramenta usada para seguir a árvore de código fonte do OpenBSD. Para instalar o CVSup em um sistema razoavelmente rápido e com uma boa conexão com a internet, leva-se aproximadamente dez segundos -- o tempo necessário para fazer o download e desempacotar um arquivo único de 779kB. Em contraste, compilar o CVSup a partir do código fonte é uma tarefa pesada, exigindo muitas ferramentas e o "bootstrapping" de um compilador, levando cerca de meia hora na mesma máquina. Outros aplicativos, como o Mozilla ou o KDE, podem levar horas e grandes quantidades de espaço em disco e RAM/swap para compilar. Por que passar por esse tempo e esforço se os programas já estão compilados e guardados no seu CD-ROM ou em um espelho FTP, esperando para serem usados?

Naturalmente, em alguns casos existem algumas boas razões para usar o portes em vez dos pacotes:

No entanto, para a maioria das pessoas e para a maioria dos aplicativos, usar pacotes é muito mais fácil e é, definitivamente, o modo recomendado de adicionar aplicativos em um sistema OpenBSD.

15.4.7 - Como eu melhoro esses portes para obter o desempenho máximo?

O OpenBSD é orientado à estabilidade e segurança. Assim como o kernel GENERIC é o padrão e o único kernel suportado, a equipe do portes se assegura que os portes funcionam e são estáveis. Se você quer usar todos os tipos de opções do compilador, você está nas suas próprias mãos. Por favor, não faça perguntas nas listas de discussão sobre por que não funciona quando você tenta usar algumas opções para tornar algo mais rápido. Geralmente, todas essas opções não são necessárias para mais de 99% dos usuários, e é comum que isso seja uma grande perda de tempo para você, o usuário, como também para os desenvolvedores que leem sobre os seus "problemas", quando na realidade não existe nenhum.

15.4.8 - Eu submeti um novo porte, ou uma atualização, semanas atrás. Por que não foi integrado ("commited")?

A equipe do portes possui recursos muito limitados e nenhum "committer" foi capaz de olhar o seu porte/atualização nesse período. Por mais frustrante que isso possa ser, apenas ignore esse fato. Tome conta do seu porte, envie atualizações, e uma hora ou outra alguém pode se ocupar com ele. Isso acontece quando essas pessoas tem algum tempo livre para integrar os portes, ou o interesse delas mudam para novas áreas e suas antigas submissões tornam-se interessantes, se elas forem lembradas.

15.5 - Como relatar um problema

Se você tem algum problema com um porte existente, envie uma mensagem de correio eletrônico para o mantenedor do porte. Para ver quem é o mantenedor do porte, digite, por exemplo:
$ cd /usr/ports/archivers/unzip
$ make show=MAINTAINER

Alternativamente, se não existe um mantenedor, ou você não pode contatá-lo(a), envie uma mensagem para a lista de discussão do portes do OpenBSD, ports@openbsd.org. Por favor, NÃO use a lista de discussão misc@openbsd.org para questões sobre o portes.

Em todo caso, forneça:

Para portes que não compilam corretamente, uma transcrição completa da compilação é quase sempre requerida. Você pode usar o script portslogger, encontrado em /usr/ports/infrastructure/build, para isso. Uma execução de exemplo do portslogger pode ser:
$ mkdir ~/portslogs
$ cd /usr/ports/archivers/unzip
$ make clean install 2>&1 | /usr/ports/infrastructure/build/portslogger \
           ~/portslogs
Depois disso, você deve ter um arquivo de registro da compilação no seu diretório ~/portslogs, que você pode enviar para o mantenedor do porte. Também tenha certeza que você não está usando nenhuma opção especial na sua compilação; em /etc/mk.conf, por exemplo.

Alternativamente, você pode

15.6 - Como nos ajudar

Existem muitos meios de você ajudar. Eles estão listados a seguir, em ordem crescente de dificuldade. Nota: Para todo o processo de criação de novos portes e testes subsequentes, ou para o teste de atualizações de portes, você precisa usar um sistema -current! Geralmente, por causa de sua contínua natureza de evolução, esse não é um ambiente desejável, então proceda somente se você tem certeza que vai seguir a -current.

[Índice da FAQ] [Seção 14 - Configuração dos Discos]


[voltar] www@openbsd.org
$OpenBSD: faq15.html,v 1.12 2010/07/17 17:38:10 ajacoutot Exp $