Manual:X86/Trabalhando/Portage

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Handbook:X86/Working/Portage and the translation is 100% complete.

Other languages:
Deutsch • ‎English • ‎español • ‎français • ‎polski • ‎português do Brasil • ‎русский • ‎українська • ‎中文(中国大陆)‎ • ‎日本語 • ‎한국어
X86 Handbook
Installation
About the installation
Choosing the media
Configuring the network
Preparing the disks
Installing stage3
Installing base system
Configuring the kernel
Configuring the system
Installing tools
Configuring the bootloader
Finalizing
Working with Gentoo
Portage introduction
USE flags
Portage features
Initscript system
Environment variables
Working with Portage
Files and directories
Variables
Mixing software branches
Additional tools
Custom package repository
Advanced features
Network configuration
Getting started
Advanced configuration
Modular networking
Wireless
Adding functionality
Dynamic management


Bem Vindo ao Portage

O Portage é uma das mais notáveis inovações do Gentoo em gerenciamento de software. Com sua grande flexibilidade e enorme quantidade de recursos ele é visto frequentemente como a melhor ferramenta de gerenciamento de software disponível para Linux.

O Portage é inteiramente escrito em Python e Bash e assim é totalmente transparente aos usuários uma vez que ambas são linguagens de scripts.

A maioria dos usuários irá trabalhar com o Portage através da ferramenta emerge. Este capítulo não foi feito para duplicar as informações disponíveis na página de manual do emerge. Para uma lista completa das opções do emerge, por favor consulte a página do manual:

user $man emerge

Repositório Gentoo

Ebuilds

Quando a documentação do Gentoo falar sobre pacotes, significa títulos de software disponíveis aos usuários Gentoo através do repositório Gentoo. Este repositório é uma coleção de ebuilds, arquivos que contém toda a informação que o Portage necessita para manter o software (instalar, procurar etc). Estas ebuilds residem no /usr/portage como padrão.

Quando alguém solicita ao Portage executar alguma ação em relação ao títulos de software, ele irá usar as ebuilds no sistema como base. É muito importante atualizar regularmente as ebuilds no sistema para que o Portage saiba sobre novo software, atualizações de segurança etc.

Atualizando o repositório Gentoo

O repositório Gentoo é normalmente atualizado com o rsync, um utilitário rápido de transferência incremental de arquivos. Atualizar é bastante simples já que o comando emerge provê um front-end para o rsync:

root #emerge --sync

Algumas vezes restrições de firewall impedem o rsync de contatar os espelhos. Neste caso, atualize o repositório Gentoo através de snapshots gerados diariamente. A ferramenta emerge-webrsync automaticamente baixa e instala o último snapshot no sistema:

root #emerge-webrsync

Uma vantagem adicional de usar emerge-webrsync é que ele permite ao administrador subir no repósitório Gentoo somente snapshots assinados com a chave GPG da engenharia de lançamentos do Gentoo. Mais informações sobre isso podem se encontradas na seção de recursos do Portage em baixando snapshots validados do repositório Gentoo.

Mantendo software

Procurando por software

Há varias maneiras de se procurar software no repositório Gentoo. Uma delas e através do próprio emerge. Como padrão, emerge --search retorna os nomes do pacotes que os títulos correspondem (completa ou parcialmente) ao termo procurado.

Por exemplo, para procurar por todos os pacotes que têm "pdf" em seus nomes:

user $emerge --search pdf

Para pesquisar através das descrições também, use a opção --searchdesc (ou -S):

user $emerge --searchdesc pdf

Note que a saída retorna muita informação. Os campos são claramente descritos de modo que não iremos detalhar seus significados:

CODE Exemplo de saída para o comando search
*  net-print/cups-pdf
      Latest version available: 1.5.2
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 15 kB
      Homepage:    http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
      Description: Provides a virtual printer for CUPS to produce PDF files.
      License:     GPL-2

Instalando software

Quando um título de software é encontrado, então a instalação necessita de apenas um comando emerge. Por exemplo, para instalar o gnumeric:

root #emerge --ask app-office/gnumeric

Uma vez que muitas aplicações dependem umas das outras, uma tentativa de instalar um certo pacote pode resultar na instalação de varias dependências também. Não se preocupe, o Portage cuida das dependências também. Para saber o que o Portage irá instalar, adicione a opção --pretend. Por exemplo:

root #emerge --pretend gnumeric

Durante a instalação do pacote, o Portage irá baixar o código fonte necessário da internet (se necessário) e armazená-lo por default em /usr/portage/distfiles/. Após isto ele irá descompactar, compilar e instalar o pacote. Para dizer ao Portage para somente baixar os fontes sem instalá-los, adicione a opção --fetchonly ao comando emerge:

root #emerge --fetchonly gnumeric

Achando a documentação de um pacote instalado

Muitos pacotes vem com sua própria documentação. Algumas vezes, a USE flag doc determina se a documentação do pacote deve ser instalada ou não. Para ver se a USE flag doc é usada por um pacote, use emerge -vp category/package:

root #emerge -vp media-libs/alsa-lib
These are the packages that would be merged, in order:
[ebuild  R    ] media-libs/alsa-lib-1.1.3::gentoo USE="python -alisp -debug -doc" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7" 0 KiB

A melhor maneira de habilitar a USE flag doc é fazendo para cada pacotes via /etc/portage/package.use, de modo que somente a documentação dos pacotes desejados é instalada. Para mais informação, por favor leia o seção USE flags.

Uma vez que o pacote esteja instalado, sua documentação é geralmente encontrada no subdiretório com o nome do pacote no diretório /usr/share/doc/:

user $ls -l /usr/share/doc/alsa-lib-1.1.3
total 16
-rw-r--r-- 1 root root 3098 Mar  9 15:36 asoundrc.txt.bz2
-rw-r--r-- 1 root root  672 Mar  9 15:36 ChangeLog.bz2
-rw-r--r-- 1 root root 1083 Mar  9 15:36 NOTES.bz2
-rw-r--r-- 1 root root  220 Mar  9 15:36 TODO.bz2

Uma forma mais confiável de listar os arquivos de documentação instalados é usar a opção --filter do equery. O equery é usado para consultar o banco de dados do Portage e faz parte do pacote app-portage/gentoolkit:

user $equery files --filter=doc alsa-lib
 * Searching for alsa-lib in media-libs ...
 * Contents of media-libs/alsa-lib-1.1.3:
/usr/share/doc/alsa-lib-1.1.3/ChangeLog.bz2
/usr/share/doc/alsa-lib-1.1.3/NOTES.bz2
/usr/share/doc/alsa-lib-1.1.3/TODO.bz2
/usr/share/doc/alsa-lib-1.1.3/asoundrc.txt.bz2

A opção --filter pode ser usada com outras regras para ver o local de instalação de muitos outros tipos de arquivos. Funcionalidades adicionais podem consultadas na página de manual do equery: man 1 equery.

Removendo software

Para remover software de um sistema, use emerge --unmerge. Isto irá dizer ao Portage para remover todos os arquivos instalados por este pacote do sistema. Uma exceção são os arquivos de configuração desta aplicação se eles foram alterados pelo usuário. Deixar os arquivos de configuração permite aos usuários continuar trabalhando com o pacote sem a necessidade de reconfiguração se os pacotes forem reinstalados mais tarde.

Aviso
O Portage não irá checar se o pacote a ser removido e requerido por outro pacote. Ele irá contudo avisar quando um pacote importante se removido pode quebrar o sistema.
root #emerge --unmerge gnumeric

Quando um pacote é removido do sistema, as dependências deste pacote que foram instaladas automaticamente são deixadas no sistemas. Para que o Portage localize todas as dependências que podem agora ser removidas, use a funcionalidade do emerge code>--depclean</code>, que será explicada mais tarde.

Atualizando o sistema

Para manter o sistema em perfeito estado (e sem mencionar com as últimas atualizações de segurança) é necessário atualizar o sistema regularmente. Uma vez que o Portage somente checa as ebuilds no repositório Gentoo, a primeira coisa a fazer é atualizar esse repositório. Quando o repositório Gentoo é atualizado, o sistema pode ser atualizado usando emerge --update @world. No próximo exemplo, a opção --ask é usada também para que o Portage mostre a lista de pacotes que serão atualizados e espere uma confirmação:

root #emerge --update --ask @world

O Portage irá então procurar por novas versões dos aplicativos que estão instalados. Contudo, ele irá somente verificar as versões dos aplicativos que estão explicitamente instaladas (as aplicações listadas em /var/lib/portage/world) - ele não irá checar suas dependências. Para atualizar as dependências destes pacotes também, adicione a opção --deep:

root #emerge --update --deep @world

Ainda assim, isto não inclui todos os pacotes: alguns pacotes no sistema são necessários apenas durante o processo de compilação. O Portage chama este pacotes build dependencies. Para incluir estes pacotes em um ciclo de atualização adicione --with-bdeps=y:

root #emerge --update --deep --with-bdeps=y @world

Uma vez que atualizações de segurança acontecem em pacotes que não estão explicitamente instalados no sistema (mas que são dependências de outros programas), é recomendado executar este comando de vez em quando.

Se as configurações USE do sistemas foram alteradas, é recomendado adicionar --newuse também. O Portage irá verificar se a alteração requer a instalação de novos pacotes ou a recompilação dos existentes:

root #emerge --update --deep --with-bdeps=y --newuse @world

Metapacotes

Alguns pacotes no repositório do Gentoo não tem nenhum conteúdo real mas são usados para instalar uma coleção de pacotes. Por exemplo, o pacote kde-plasma/plasma-meta irá instalar o desktop KDE Plasma completo no sistema baixando os vários pacotes relacionados ao Plasma e sua dependências.

Para remover esse pacote de seu sistema, executar emerge --unmerge no pacote não tem muito efeito já que suas dependências ficarão no sistema.

O Portage tem a funcionalidade de remover também dependências órfãs, mas uma vez a disponibilidade de software é dinamicamente dependente, é importante primeiro atualizar completamente o sistema, incluindo as novas alterações nas USE flags. Feito isso pode-se executar emerge --depclean para remover as dependências órfãs. Quando concluído, pode ser necessário recompilar as aplicações que foram linkadas dinamicamente aos agora removidos softwares mas não os requerem mais, suporte recente para isto foi adicionado ao Portage.

Tudo isso é feito com os três seguintes comandos:

root #emerge --update --deep --newuse @world
root #emerge --depclean
root #revdep-rebuild

revdep-rebuild é fornecido pelo pacote app-portage/gentoolkit; não esqueça de emerge:

root #emerge --ask app-portage/gentoolkit

Licenças

A partir do Portage versão 2.1.7, é possível aceitar ou rejeitar a instalação de software baseado em sua licença. Todos os pacotes na árvore contém uma LICENSE em suas ebuilds. Executando emerge --search package/category irá mostrar a licença do pacote.

Como padrão, o Portage permite todas as licenças, exceto End User License Agreements (EULAs) que requerem leitura e assinatura em aceitação.

A variável que controla as licenças permitidas é chamada ACCEPT_LICENSE, que pode ser configurada no arquivo /etc/portage/make.conf. No próximo exemplo, seu valor padrão é mostrado:

FILE /etc/portage/make.confA configuração ACCEPT_LICENSE padrão
ACCEPT_LICENSE="* -@EULA"

Com esta configuração, os pacotes que requerem interação durante a aprovação de sua EULA não serão instaláveis. Pacotes sem uma EULA serão instaláveis.

É possível configurar ACCEPT_LICENSE globalmente no /etc/portage/make.conf, ou especificá-la por pacote no arquivo /etc/portage/package.license.

Por exemplo, para permitir a licença google-chrome para o pacote www-client/google-chrome, adicione o seguinte em /etc/portage/package.license:

FILE /etc/portage/package.licenseAceitando a licença google-chrome para o pacote google-chrome
www-client/google-chrome google-chrome

Isto permite a instalação do pacote www-client/google-chrome, mas proíbe a instalação do pacote www-plugins/chrome-binary-plugins, mesmo que eles tenham a mesma licença.

Importante
Licenças são guardadas no diretório /usr/portage/licenses/, e grupos de licenças são mantidas no arquivo /usr/portage/profiles/license_groups. A primeira entrada de cada linha em MAIÚSCULAS é o nome do grupo de licenças, e cada entrada depois desta é uma licença individual.

Grupos de licença definidos na variável ACCEPT_LICENSE são prefixadas com um sinal @. Uma configuração comumente requerida é para somente permitir a instalação de software e documentação livre. Para conseguir isto, remova todas a licenças atualmente aceitas (usando -*) e então permita somente as licenças no grupo FREE como segue:

FILE /etc/portage/make.confSomente aceita software e documentação livre
ACCEPT_LICENSE="-* @FREE"

Neste caso, "livre" é, na maioria das vezes, definido pela FSF e OSI. Qualquer pacote que não atendam esses requisitos de licença não serão instaláveis no sistema.

Quando o Portage reclamar

Terminologia

Como dito antes, o Portage é extremamente poderoso e suporta muitas funções que outros gerenciadores de software não tem. Para entender isto, explicaremos uns poucos aspectos do Portage sem entrar em muitos detalhes.

Com o Portage diferentes versões de um mesmo pacote podem coexistir em um sistema. Enquanto outras distribuições tendem a dar nomes em seus pacotes para essas versões (como freetype e freetype2) o Portage usa uma terminologia chamada "SLOT". Um ebuild declara um certo SLOT para sua versão. Ebuilds com diferentes SLOTs podem coexistir em um mesmo sistema. Por exemplo, o pacote freetype tem ebuilds com SLOT="1" e SLOT="2".

Há também pacotes que proveem a mesma funcionalidade mas são implementados de forma diferente. Por exemplo, metalogd, sysklogd, e syslog-ng são todos sistemas de log. Aplicações que para sua disponibilidade precisam de um "sistema de log" não podem depender, por exemplo, do metalogd, se há outras opções de sistemas de log. O Portage permite virtuais: cada sistema de log é listado com uma "exclusiva" dependência de um serviço de log em um pacote virtual de uma categoria virtual, então estas aplicação pode depender do pacote virtual/logger. Quando instalado, o pacote irá baixar o primeiro pacote de log mencionado neste pacote, a não ser que um pacote de log já esteja instalado (neste caso a virtual já foi satisfeita).

Software no repositório Gentoo pode residir em diferentes ramos. Como padrão o sistema somente aceita pacotes que o Gentoo considera estáveis. Muitos títulos de software novos, quando enviados, são adicionados ao ramo de teste, significando que mais testes são necessários antes que ele seja marcado como estável. Mesmo que os ebuilds deste software esteja no repositório Gentoo, o Portage não irá atualizá-los se eles não forem colocados no ramo estável.

Alguns softwares estão disponíveis somente para umas poucas arquiteturas, ou precisam de mais testes, ou o desenvolvedor que enviou o software para o repositório Gentoo não conseguiu verificar se o pacote trabalha em uma arquitetura diferente.

Cada instalação do Gentoo adere a um certo perfil que contém, além de outras informações, a lista de pacotes que são requeridos para o sistema funcionar normalmente.

Pacotes bloqueados

CODE Portage avisando sobre pacotes bloqueados (com --pretend)
[blocks B     ] mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1)
CODE Portage avisando sobre pacotes bloqueados (sem --pretend)
!!! Error: the mail-mta/postfix package conflicts with another package.
!!!        both can't be installed on the same system together.
!!!        Please use 'emerge --pretend' to determine blockers.

Ebuilds contem campos específicos que informam ao Portage sobre suas dependências. Há duas dependências possíveis: dependências de build, declaradas na variável DEPEND e dependências de execução, declaradas em RDEPEND. Quando uma dessas dependências indica explicitamente que um pacotes ou virtual não e compatível, um bloqueio é disparado.

Enquanto versões recentes do Portage são inteligentes o bastante para resolver bloqueios menores sem intervenção do usuário, ocasionalmente alguns bloqueios precisam ser resolvidos manualmente.

Para corrigir um bloqueio, usuários podem escolher não instalar o pacote ou fazer unmerge do pacore conflitante primeiro. Neste exemplo, podemos optar por não instalar o postfix ou remover o ssmtp primeiro.

Algumas vezes há também pacotes bloqueados com versões específicas, como <media-video/mplayer-1.0_rc1-r2. Neste caso, atualizar para uma versão mais recente do pacote pode remover o bloqueio.

É possível também que dois pacotes que estão para ser instalados bloqueiem um ao outro. Nesses casos raros, tente achar porque ambos precisam ser instalados. Na maioria dos casos apenas um deles é suficiente. Se não, por favor crie um bug no sistema de acompanhamento de bugs do Gentoo.

Pacotes mascarados

CODE Portage avisando sobre pacotes mascarados
!!! all ebuilds that could satisfy "bootsplash" have been masked.
CODE Portage avisando sobre pacotes mascarados - razão
!!! possible candidates are:
  
- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword)
- lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword)
- sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- games-fps/unreal-tournament-451 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)
- net-im/skype-2.1.0.81 (masked by: skype-eula license(s))

Quando tentar instalar um pacote que não está disponível para o sistema, este erro de mascaramento ocorre. Usuários devem tentar instalar uma aplicação diferente que esteja disponível para o sistema ou esperar até o pacote ser marcado como disponível. Há sempre uma razão porque o pacote é mascarado:

Razões para mascaramento Descrição
palavra chave ~arch A aplicação não foi testada o suficiente para ser colocada no ramo estável. Espere uns dias ou semanas e tente novamente.
palavra chave -arch ou -* A aplicação não funciona em sua arquitetura. Se você acredita que o pacote funciona coloque um bug em nosso site Bugzilla.
palavra chave missing A aplicação não foi testada em sua arquitetura ainda. Pergunte ao time de arquitetura se eles podem testar o pacote ou teste para eles e faça um relatório em nosso site Bugzilla.
package.mask O pacote está corrompido, instável ou pior, foi deliberadamente marcado como inútil.
profile O pacote encontrado não é adequado ao perfil atual. A aplicação pode quebrar o sistema se instalada ou não é compatível com o perfil atualmente usado.
license A licença do pacote não é compatível com o valor ACCEPT_LICENSE. Habilite esta licença ou seu grupo configurando em /etc/portage/make.conf ou em /etc/portage/package.license

Mudanças necessárias nas USE flags

CODE Portage avisando sobre a necessidade de alteração na USE flag
The following USE changes are necessary to proceed:
#required by app-text/happypackage-2.0, required by happypackage (argument)
>=app-text/feelings-1.0.0 test

A mensagem de erro pode também ser mostrada como segue, se --autounmask não estiver habilitado:

CODE Erro do Portage sobre a necessidade de alteração na USE flag
emerge: there are no ebuilds built with USE flags to satisfy "app-text/feelings[test]".
!!! One of the following packages is required to complete your request:
- app-text/feelings-1.0.0 (Change USE: +test)
(dependency required by "app-text/happypackage-2.0" [ebuild])
(dependency required by "happypackage" [argument])

Este aviso ou erro ocorre quando um pacote é requerido para instalação ao qual não depende de outro pacote, mas este pacote requer um USE flag em particular para compilação (o conjunto de USE flags). No exemplo dado, o pacote app-text/feelings precisa ser compilado com USE="test", mas esta USE flags não está habilitada no sistema.

Para resolver isso, adicione a USE flag requerida para as USE flags globais em /etc/portage/make.conf, ou habilite para um pacote específico em /etc/portage/package.use.

Dependências faltantes

CODE Portage avisando sobre dependências faltantes
emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".
  
!!! Problem with ebuild sys-devel/gcc-3.4.2-r2
!!! Possibly a DEPEND/*DEPEND problem.

A aplicação a ser instalada depende de outro pacote que não está disponível para o sistema. Por favor cheque no Bugzilla se o problema é conhecido e se não, por favor faça um relatório. A não se que o sistema esteja configurado para mais de um ramo isto não deve ocorrer e provavelmente é um bug.

Nome do ebuild ambíguo

CODE O Portage avisando sobre nomes de ebuild ambíguos
[ Results for search key : listen ]
[ Applications found : 2 ]
  
*  dev-tinyos/listen [ Masked ]
      Latest version available: 1.1.15
      Latest version installed: [ Not Installed ]
      Size of files: 10,032 kB
      Homepage:      http://www.tinyos.net/
      Description:   Raw listen for TinyOS
      License:       BSD
  
*  media-sound/listen [ Masked ]
      Latest version available: 0.6.3
      Latest version installed: [ Not Installed ]
      Size of files: 859 kB
      Homepage:      http://www.listen-project.org
      Description:   A Music player and management for GNOME
      License:       GPL-2
  
!!! The short ebuild name "listen" is ambiguous. Please specify
!!! one of the above fully-qualified ebuild names instead.

A aplicação selecionada para instalação tem seu nome que corresponde a mais de um pacote. Forneça também a nome da categoria para resolver isso. O Portage irá informar o usuário sobre as possíveis opções a escolher.

Dependências circulares

CODE Portage avisando sobre dependência circular
!!! Error: circular dependencies: 
  
ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2

Dois (ou mais) pacotes a instalar dependem um do outro e não podem ser instalados. Isso é na maioria da vezes um bug em um dos pacotes do repositório Gentoo. Por favor sincronize novamente e tente mais tarde. Pode ser bom checar o Bugzilla para ver se o problema é conhecido e, se não, fazer um relatório dele.

Falha ao baixar

CODE Portage avisando sobre falha ao baixar
!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered.  Please see above for details.

O Portage não conseguiu fazer o download dos fontes da aplicação e irá tentar continuar instalando outras aplicações (se aplicável). Esta falha pode acontecer devido um espelho não estar sincronizado corretamente ou por causa de um ebuild apontar para um local incorreto. O servidor onde os fontes residem podem também estar fora do ar por alguma razão.

Tente novamente em uma hora para ver se o problema ainda persiste.

Proteção do perfil do sistema

CODE Portage avisando sobre um pacote protegido pelo perfil
!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.

O usuário tentou remover um pacote que é parte do núcleo de pacotes do sistema. Ele é listado como requerido pelo perfil e não deve ser removido do sistema.

Falha na verificação do resumo

CODE Falha na verificação do resumo
>>> checking ebuild checksums
!!! Digest verification failed:

Isto é um sinal que algo está errado com repositório Gentoo - frequentemente por causa de um desenvolvedor ter cometido algum erro quando no envio de um ebuild para o repositório de ebuilds do Gentoo.

Quando uma verificação de resumo falhar, não tente refazer o resumo novamente do pacote pessoalmente. Executar ebuild foo manifest não irá corrigir o problema; irá muito provavelmente fazê-lo pior!

Em vez disso, espere um hora ou duas até o repositório se estabilizar. É provável que o erro foi notado de imediato, mas pode levar um tempo para a correção chegar até os espelhos rsync. Cheque o Bugzilla e veja se alguém já reportou o problema ou pergunte no #gentoo (IRC). Se não, vá em frente e abra um bug para o ebuild com problema.

Uma vez que o bug foi corrigido, sincronize novamente o repositório de ebuild do Gentoo para obter o resumo corrigido.

Importante
Tenha cuidado para não sincronizar o repositório de ebuild do Gentoo mais de uma vez ao dia. Como declarado na política de etiqueta oficial do Gentoo (assim como quando executamos o emerge --sync), usuários que sincronizarem muito frequentemente serão barrados de sincronizar por um tempo. Usuários que repetidamente violarem essa política podem ser banidos. A menos que absolutamente necessário, é melhor esperar um período de 24 horas para sincronizar de modo que a ressincronização não sobrecarregue os espelhos rsync do Gentoo.