Guia básico para escrever ebuilds Gentoo

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Basic guide to write Gentoo Ebuilds and the translation is 69% complete.
Outdated translations are marked like this.

Este é um guia para começar a escrever ebuilds, para aproveitar o poder do Portage, para instalar e gerenciar ainda mais software.Property "Descrição do artigo" (as page type) with input value "começar a escrever ebuilds, para aproveitar o poder do Portage, para instalar e gerenciar ainda mais software." contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

Escreva um ebuild para instalar um software no Gentoo, quando não houver ebuilds pré-existentes adequados. É uma tarefa relativamente simples e é a única maneira de instalar de forma limpa a maioria dos softwares de "terceiros" em todo o sistema. O ebuild permitirá que o gerenciador de pacotes rastreie todos os arquivos instalados no sistema, para permitir atualizações e remoções limpas.

Dica
Do artigo ebuild: Um arquivo ebuild é um arquivo de texto, normalmente armazenado em um repositório, que identifica um pacote de software específico e diz ao gerenciador de pacotes do Gentoo como manipulá-lo. Ebuilds usam um estilo de sintaxe parecido com bash e são padronizados através da Especificação do Gerenciador de Pacotes, aderindo a uma versão especifica da EAPI.

Os ebuilds contêm metadados sobre cada versão de um software disponível (nome, número da versão, licença, endereço da página inicial...), informações de dependência (tanto em tempo de compilação quanto em tempo de execução) e instruções sobre como compilar e instalar o software (configurar, compilar, instalar, testar...).

Quando um ebuild estiver funcionando, ele poderá ser compartilhado enviando-o em um pull request ou em um repositório ebuild separado e tornando-o acessível publicamente. Com um pouco de esforço, os ebuilds podem ser propostos e mantidos no repositório GURU.

Nota
Veja o manual do desenvolvedor de escrita de ebuilds para obter a documentação de referência completa. Consulte o início rápido para escrever ebuilds no manual do desenvolvedor para obter mais exemplos de como escrever ebuilds. Consulte o artigo ebuild para obter explicações sobre os próprios ebuilds, o artigo repositório de ebuild sobre o que é um repositório de ebuild e o artigo criando um repositório de ebuild sobre como criá-los

.

Para que os ebuilds estejam disponíveis para o Portage, eles são colocados em um repositório de ebuild que está configurado para o Portage por meio de /etc/portage/repos.conf (consulte a seção gerenciamento de repositório para obter informações gerais sobre como trabalhar com repositórios ebuild).

Crie um repositório de ebuild para fazer experimentos, enquanto segue este guia. O restante do artigo considerará um repositório em /var/db/repos/example_repository.

eselect repository torna simples a criação de um repositório:

root #eselect repository create example_repository
Nota
Ebuilds podem ser instalados com o comando ebuild, entretanto isso não é recomendado - este comando é apenas para fins de desenvolvimento. Este artigo usará o comando ebuild com o arquivo ebuild para teste durante o desenvolvimento, mas certifique-se de usar o comando emerge com um ebuild em um repositório.

Como criar um ebuild

Os ebuilds são simplesmente arquivos de texto, em sua forma mais básica. Tudo o que é necessário para começar a escrever ebuilds é um editor de texto, para proporcionar pacotes de software instaláveis para o Gentoo.

Nota
Nesta seção, {CATEGORY}, {PN} e {P} representam categoria do pacote, nome do pacote e nome e versão do pacote, e são variáveis padrão usadas em ebuilds. Juntas, essas variáveis podem representar um especificador de versão.

Alguns editores têm a funcionalidade opcional de ebuild; nesse caso, pule para a seção apropriada. Caso contrário, um esqueleto ("modelo") pode ser usado para começar mais rapidamente.

Começo com o esqueleto

Se o editor não tiver a funcionalidade ebuild integrada para ajudar a começar, há um arquivo ebuild de esqueleto (skel.ebuild) localizado no repositório de ebuild do Gentoo. Para começar com esse arquivo como base, basta copiá-lo em um local apropriado (nano é usado como editor de texto neste exemplo):

user $mkdir --parents /var/db/repos/example_repository/{CATEGORY}/{PN}
user $cp /var/db/repos/gentoo/skel.ebuild /var/db/repos/example_repository/{CATEGORY}/{PN}
user $cd /var/db/repos/example_repository/{CATEGORY}/{PN}
user $nano {P}.ebuild

Vim

Há um plugin do vim para iniciar automaticamente com um esqueleto ao criar um arquivo ebuild vazio.

Depois de instalar app-vim/gentoo-syntax, crie o diretório apropriado para o ebuild e, em seguida, inicie vim com um novo nome de arquivo "{P}.ebuild" fornecido na linha de comando, para receber automaticamente um esqueleto básico que pode ser modificado e salvo:

user $mkdir --parents /var/db/repos/example_repository/{CATEGORY}/{PN}
user $cd /var/db/repos/example_repository/{CATEGORY}/{PN}
user $vim {P}.ebuild

Emacs

Uma ferramenta semelhante está disponível para usuários do Emacs, fornecida por app-emacs/ebuild-mode ou app-xemacs/ebuild-mode, dependendo da distribuição do Emacs.

Language server

Demonstração por exemplo

Este exemplo criará um ebuild para scrub, versão 2.6.1 (se ainda não existir), para mostrar como um processo típico pode ocorrer.

Crie um diretório para abrigar o ebuild, no repositório ebuild criado anteriormente:

user $mkdir -p /var/db/repos/example_repository/app-misc/scrub

Altere o diretório de trabalho do shell para o novo caminho:

user $cd /var/db/repos/example_repository/app-misc/scrub
Dica
Alguns shells, como o Bash, fornecem o último parâmetro do comando anterior na variável "$_". Isso pode ser usado para chamar o diretório recém-criado sem especificar o caminho na linha de comando, desde que seja usado diretamente como o próximo comando.
user $cd $_

Este exemplo usará o Vim para criar o arquivo ebuild e fornecer um esqueleto para servir de base para escrever o ebuild, mas use o editor de sua preferência (consulte a seção anterior sobre o uso do Emacs ou do arquivo esqueleto):

user $vim ./scrub-2.6.1.ebuild

Adicione informações importantes sobre o novo pacote configurando as variáveis definidas pelo ebuild: DESCRIPTION, HOMEPAGE, SRC_URI, LICENSE:

FILE scrub-2.6.1.ebuildeditando um novo arquivo no vim a partir do modelo
# Copyright 1999-2024 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
 
EAPI=8
 
DESCRIPTION="Some words here"
HOMEPAGE="https://github.com/chaos/scrub"
SRC_URI="https://github.com/chaos/scrub/releases/download/2.6.1/scrub-2.6.1.tar.gz"
 
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE=""
 
DEPEND=""
RDEPEND="${DEPEND}"
BDEPEND=""

Essas — com a omissão das linhas com ="" — são as informações mínimas necessárias para obter algo que funcione. Os ebuilds que herdam determinadas eclasses podem vir com um conjunto diferente de informações mínimas, por exemplo, ant-jsch-1.10.9.ebuild. Salve o arquivo - voilà, um ebuild, em sua forma mais básica, é simples assim!

Nota
Usar a variável ${PN} dentro de SRC_URI é permitido, embora isso não seja necessariamente a melhor prática. Embora possa ser mais curto para digitar, há alguns raciocínios sobre por que não usá-lo que pode valer a pena considerar.

CODE evite usar PN desse jeito
SRC_URI="https://github.com/gentoo/${PN}/releases/download/${PV}/${P}.tar.gz"
# Reads better as, e.g.
SRC_URI="https://github.com/gentoo/gentoo/releases/download/${PV}/${P}.tar.gz"

Veja esta página de guia de política de formato de arquivo ebuild para mais recomendações.

É possível testar a obtenção e a descompactação dos códigos-fonte originais pelo novo ebuild, usando o comando ebuild:

user $GENTOO_MIRRORS="" ebuild ./scrub-2.6.1.ebuild manifest clean unpack
Appending /var/db/repos/customrepo to PORTDIR_OVERLAY...
>>> Downloading 'https://github.com/chaos/scrub/releases/download/2.6.1/scrub-2.6.1.tar.gz'
--2023-03-03 23:35:13--  https://github.com/chaos/scrub/releases/download/2.6.1/scrub-2.6.1.tar.gz
Resolving github.com... 140.82.121.4
Connecting to github.com|140.82.121.4|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://objects.githubusercontent.com/github-production-release-asset-2e65be/23157201/405a65b8-2d4d-11e4-8f82-3e3a9951b650?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230303%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230303T223513Z&X-Amz-Expires=300&X-Amz-Signature=7d7d925ff8392ee2ba12028c73c8d8c3b3a7086b5aec11bbfae335222a4f2eb0&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=23157201&response-content-disposition=attachment%3B%20filename%3Dscrub-2.6.1.tar.gz&response-content-type=application%2Foctet-stream [following]
--2023-03-03 23:35:13--  https://objects.githubusercontent.com/github-production-release-asset-2e65be/23157201/405a65b8-2d4d-11e4-8f82-3e3a9951b650?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230303%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230303T223513Z&X-Amz-Expires=300&X-Amz-Signature=7d7d925ff8392ee2ba12028c73c8d8c3b3a7086b5aec11bbfae335222a4f2eb0&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=23157201&response-content-disposition=attachment%3B%20filename%3Dscrub-2.6.1.tar.gz&response-content-type=application%2Foctet-stream
Resolving objects.githubusercontent.com... 185.199.108.133, 185.199.109.133, 185.199.110.133, ...
Connecting to objects.githubusercontent.com|185.199.108.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 362536 (354K) [application/octet-stream]
Saving to: '/var/cache/distfiles/scrub-2.6.1.tar.gz.__download__'
 
/var/cache/distfiles/scrub-2.6.1. 100%[============================================================>] 354.04K  --.-KB/s    in 0.08s   
 
2023-03-03 23:35:13 (4.31 MB/s) - '/var/cache/distfiles/scrub-2.6.1.tar.gz.__download__' saved [362536/362536]
 
 * scrub-2.6.1.tar.gz BLAKE2B SHA512 size ;-) ...                                                                               [ ok ]
>>> Unpacking source...
>>> Unpacking scrub-2.6.1.tar.gz to /var/tmp/portage/app-misc/scrub-2.6.1/work
>>> Source unpacked in /var/tmp/portage/app-misc/scrub-2.6.1/work

Isso deve baixar e descompactar o tarball de código-fonte, sem erros, como no exemplo de saída.

Para alguns pacotes excepcionalmente simples como este, que não precisam de patches ou de outro tratamento mais avançado, o ebuild pode funcionar exatamente assim, sem a necessidade de outros ajustes.

Como prática recomendada, o conjunto de testes pode ser executado nesse estágio, o que é especialmente verdadeiro no início:

root #ebuild scrub-2.6.1.ebuild clean test install

Para instalar de fato o novo ebuild no sistema, execute:

root #ebuild scrub-2.6.1.ebuild clean install merge

Correção do código-fonte original em um ebuild

Um patch pode ser criado a partir do código-fonte descompactado, conforme explicado no artigo Criando um patch. Os patches devem então ser listados em um array chamado PATCHES conforme explicado no devmanual:

CODE Os patches serão aplicados durante src_prepare
PATCHES=(
	"${FILESDIR}"/${P}-foo.patch
	"${FILESDIR}"/${P}-bar.patch
)
 
src_prepare() {
    default
    ...
}

Teste de controle de qualidade

Use pkgcheck (dev-util/pkgcheck) para verificar erros de controle de qualidade em um ebuild:

user $pkgcheck scan

Veja também

Recursos externos