![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[Índice da FAQ] [Seção 14 - Configuração dos Discos]
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.
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:
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".
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.
$ 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.
$ 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:
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.$ 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
É 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):
Algumas vezes você pode encontrar um erro igual ao do exemplo a seguir:$ 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
$ 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.
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:
$ 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.
$ 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.
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.
$ 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.
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.
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:
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:
| 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.
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.
SUDO=/usr/bin/sudo
# chgrp -R wsrc /usr/ports
# find /usr/ports -type d -exec chmod g+w {} \;
Isso força o procedimento de compilação a permanecer dentro dos diretórios permitidos, e proíbe a escrita em lugares ilegais, reduzindo, dessa forma, o risco de danos ao sistema. Note que o uso do systrace(1) aumenta em cerca de 20% o tempo de compilação.USE_SYSTRACE=Yes
É 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:
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.WRKOBJDIR=/usr/obj/ports DISTDIR=/usr/distfiles PACKAGE_REPOSITORY=/usr/packages
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.$ 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
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:
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.$ 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>
$ 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:
Adicionalmente, você também pode limpar os diretórios de trabalho de todas as dependências do porte, com este alvo make:$ make clean ===> Cleaning for rsnapshot-1.2.9
Se você deseja remover o conjunto de arquivos de distribuição do porte, você pode usar$ make clean=depends ===> Cleaning for rsync-2.6.9 ===> 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=dist ===> Cleaning for rsnapshot-1.2.9 ===> Dist cleaning for rsnapshot-1.2.9
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 clean=flavors
$ make package BULK=Yes
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 uninstall ===> Deinstalling for rsnapshot-1.2.9 rsnapshot-1.2.9: complete Clean shared items: complete
Se você quer se livrar dos pacotes que criou, você pode fazer o seguinte:$ 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
$ make clean=packages ===> Cleaning for rsnapshot-1.2.9 rm -f /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz
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
Você deve também olhar os arquivos DESCR do porte, já que é esperado que eles expliquem os sabores disponíveis.$ make show=FLAVORS
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
É 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).$ make show=MULTI_PACKAGES
$ 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.
É 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.
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.
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.
Mais respostas para essa pergunta também são encontradas na FAQ 1.
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:
$ 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:
$ mkdir ~/portslogs
$ cd /usr/ports/archivers/unzip
$ make clean install 2>&1 | /usr/ports/infrastructure/build/portslogger \
~/portslogs
Alternativamente, você pode
[Índice da FAQ] [Seção 14 - Configuração dos Discos]
![[voltar]](../../images/back.gif){kind=small}
www@openbsd.org