Handbook:HPPA/Working/Portage/pt-br
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 emergeRepositório Gentoo
Ebuilds
Quando a documentação do Gentoo falar sobre pacotes, isso significa títulos de software disponíveis aos usuários Gentoo através do repositório Gentoo. Esse 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). Essas ebuilds residem em /var/db/repos/gentoo 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 --syncAlgumas 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-webrsyncMantendo 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 pdfPara pesquisar através das descrições também, use a opção --searchdesc (ou -S):
user $emerge --searchdesc pdfNote que a saída retorna muita informação. Os campos são claramente descritos de modo que não iremos detalhar seus significados:
* 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/gnumericUma 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 gnumericTo do the same, but interactively choose whether or not to proceed with the installation, add the --ask flag:
root #emerge --ask gnumericDurante 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 /var/cache/distfiles/. Em seguida 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 gnumericAchando 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-libThese 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.3total 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.
root #emerge --unmerge gnumericQuando 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, 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:
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 @worldSe 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 @worldMetapacotes
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-rebuildLicenç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.
A variável LICENSE em uma ebuild é apenas uma indicação para os desenvolvedores e usuários do Gentoo. Ela não tem valor legal e não há garantias de que reflita a realidade. Desse modo, não confie cegamente nela, mas cheque o pacote em si cuidadosamente, incluindo todos os arquivos que usar.
If a discrepancy is found in the ebuild, please file a bug to suggest a change to the value(s) assigned to the ebuild's LICENSE variable.}}
Como padrão, o Portage permite as licenças que são explicitamente aprovadas pela Free Software Foundation, pela Open Source Initiative, ou que seguem a Free Software Definition.
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:
/etc/portage/make.confA configuração ACCEPT_LICENSE padrãoACCEPT_LICENSE="-* @FREE"
Com esta configuração, os pacotes de software ou documentação com uma licença livre serão instaláveis. Softwares não livres não 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:
/etc/portage/package.licenseAceitando a licença google-chrome para o pacote google-chromewww-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.
Or to allow the often-needed sys-kernel/linux-firmware:
/etc/portage/package.licenseAccepting the licenses for the linux-firmware package# Accepting the license for linux-firmware
sys-kernel/linux-firmware linux-fw-redistributable
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# Accepting any license that permits redistribution
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
Licenças são guardadas no diretório /var/db/repos/gentoo/licenses/, e grupos de licenças são mantidas no arquivo /var/db/repos/gentoo/profiles/license_groups. A primeira entrada de cada linha em MAIÚSCULAS é o nome do grupo de licenças, e cada entrada depois dessa é uma licença individual.
Grupos de licença definidos na variável ACCEPT_LICENSE são prefixadas com um sinal @. Uma configuração possível (que era o default antigo do Portage) é permitir todas as licenças, exceto End User License Agreements (EULAs) que requerem a leitura e aceitação de um termo de aceitação. Para conseguir isso, aceite todas as licenças (usando *) e então remova as licenças do grupo EULA, como abaixo:
/etc/portage/make.confAceite todas as licenças exceto EULAsACCEPT_LICENSE="* -@EULA"
Note que essa configuração irá aceitar também software e documentação não livres.
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
[blocks B ] mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1)
- Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
(x11-wm/i3-4.20.1:0/0::gentoo, ebuild scheduled for merge) pulled in by
x11-wm/i3
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
!!! all ebuilds that could satisfy "bootsplash" have been masked.
!!! 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
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:
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
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
[ 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
!!! 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
!!! 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
!!! 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
>>> 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 (webchat) (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.
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.