Guia básico para escrever ebuilds Gentoo
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.
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.
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
.
Repositórios de Ebuild
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
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.
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
There is a language server for gentoo ebuild.
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
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:
# 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!
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.
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:
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
- GitHub Pull Requests — how to contribute to Gentoo by creating pull requests on GitHub.
- java-ebuilder — an experimental package being developed by Gentoo Java developers to generate initial ebuilds from Maven
pom.xml
files. - Notes on ebuilds with GUI
- Project:GURU — an official repository of new Gentoo packages that are maintained collaboratively by Gentoo users
- Project:Proxy_Maintainers/User_Guide/Style_Guide
- Project:Python — as páginas do projeto Python têm informações sobre a criação de ebuilds para pacotes escritos em Python
- Project:X11/Ebuild_maintenance
- Proxied Maintainer FAQ
- Test environment
- Writing go Ebuilds — a short reference, intended to be read alongside Basic guide to write Gentoo Ebuilds and the go-module.eclass documentation
Recursos externos
- Gentoo Policy Guide
- Quickstart Ebuild Guide
- Gentoo Development guide
- Michał Górny: Category: Ebuild writing
- Michał Górny: The ultimate guide to EAPI 7
- Michał Górny: The ultimate guide to EAPI 8
- man 1 ebuild — The ebuild command's man page.
- man 5 ebuild — The ebuild file format man page.
- The skel.ebuild
- Adding new packages via proxy-maint project