Guida di base per scrivere Ebuild 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 3% complete.
Outdated translations are marked like this.
Other languages:

Questo articolo contiene istruzioni per i principianti nella sviluppo degli ebuild.

Write an ebuild to install a piece of software on Gentoo, when there are no suitable preexisting ebuilds. It's a relatively straight forward task, and is the only way to cleanly install most "third party" software system-wide. The ebuild will allow the package manager to track every file installed to the system, to allow clean updates and removal.

Suggerimento
From the ebuild article: An ebuild file is a text file, usually stored in a repository, which identifies a specific software package and tells the Gentoo package manager how to handle it. Ebuilds use a bash-like syntax style and are standardized through the Package Manager Specification, by adhering to a specific EAPI version.

Ebuilds contain metadata about each version of a piece of available software (name, version number, license, home page address...), dependency information (both build-time and run-time), and instructions on how to build and install the software (configure, compile, build, install, test...).

Once an ebuild is working, it can be shared by submitting it in a pull request or in a separate ebuild repository and making it accessible publicly. With a little effort, ebuilds can be proposed and maintained in the GURU repository.

Nota
See the dev manual on writing ebuilds for full reference documentation. See the quick start to writing ebuilds in the dev manual for further examples of how to write ebuilds. See the ebuild article for explanations about ebuilds themselves, the ebuild repository article about what an ebuild repository is, and the creating an ebuild repository article on how to create them.

Ebuilds: Dove vivono?

In order for ebuilds to be available to Portage, they are placed in an ebuild repository that is configured for Portage through /etc/portage/repos.conf (see the section on repository management for general information about working with ebuild repositories).

Create an ebuild repository to experiment in, while following on with this guide. The rest of the article will consider a repository in /var/db/repos/example_repository.

eselect repository makes creating a repository simple:

root #emerge -a app-eselect/eselect-repository
root #eselect repository create example_repository
Nota
Ebuilds can be installed with the ebuild command, however this is not recommended - this command is for development purposes only. This article will use the ebuild command with the ebuild file for testing during development, but be sure to use the emerge command with an ebuild in a repository otherwise.

Come creare un ebuild

Ebuilds are simply text files, in their most basic form. All that is needed to start writing ebuilds is a text editor, to provide installable software packages for Gentoo.

Nota
In this section, {CATEGORY}, {PN}, and {P} represent package category, package name, and package name and version, and are standard variables used in ebuilds. Together, these variables can represent a version specifier.

Some editors have optional ebuild functionality, in that case there skip to the appropriate section. Otherwise a skeleton ("template") may be used to get started quicker.

Start with the skeleton

Utenti di altri editro di testo devono manualmente copiare lo skel.ebuild:

root #cp /var/db/repos/gentoo/skel.ebuild ./foobar.ebuild

Vim

There is a vim plugin to automatically start from a skeleton when creating an empty ebuild file.

Utenti di vim ottengono lo schema base automaticamente (ottenuto da app-vim/gentoo-syntax):

root #vim ./foobar.ebuild

Emacs

Un programma similare è disponibile per gli utenti di GNU Emacs o XEmacs (ottenuto rispettivamente da app-emacs/ebuild-mode o app-xemacs/ebuild-mode).

Language server

There is a language server for gentoo ebuild.

Esempio per un codice sorgente dato

Creazione di un ebuild per scrub, versione 2.6.1 (se questa non esiste attulmente) potrebbe essere:

Create a directory to house the ebuild, in the ebuild repository created earlier:

root #mkdir -p /var/db/repos/larry/app-misc/scrub

Change the shell working directory to the new path:

root #cd $_
Suggerimento
Some shells, such as Bash, provide the last parameter of the previous command in the "$_" variable. This can be used to call the newly created directory without specifying the path on the command line, as long as this is used as the directly next command.
user $cd $_

This example will use Vim to create the ebuild file and provide a skeleton to serve as a basis to write the ebuild on, but use editor of choice (see previous section about using Emacs, or the skeleton file):

root #vim ./scrub-2.6.1.ebuild

Informazioni essenziali del nuovo pacchetto devono essere conosciute e aggiunte a ebuild-defined variables DESCRIPTION, HOMEPAGE, SRC_URI, LICENSE.

FILE scrub-2.6.1.ebuildvim comincia dal template
# Copyright 1999-2024 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
 
EAPI=7
 
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=""

This — with the omission of those lines with ="" — is the minimum information necessary to get something that will work. Ebuilds inheriting certain eclasses might come with a different set of minimal information, e.g. ant-jsch-1.10.9.ebuild. Save the file - voila an ebuild, in its most basic form, it's that simple!

Nota
Usare la variabile ${PN} è concesso, ma non consigliato. Anche se potrebbe restringere la linea, qualche vale la pena considerare anche il motivo per cui non usarlo.

Può essere testato usando il comando ebuild:

root #ebuild ./scrub-2.6.1.ebuild clean unpack
Appending /var/db/repos/larry to PORTDIR_OVERLAY...
>>> Downloading 'https://ftp.halifax.rwth-aachen.de/gentoo/distfiles/scrub-2.6.1.tar.gz'
--2019-06-03 16:42:57--  https://ftp.halifax.rwth-aachen.de/gentoo/distfiles/scrub-2.6.1.tar.gz
Resolving ftp.halifax.rwth-aachen.de... 137.226.34.46, 2a00:8a60:e012:a00::21
Connecting to ftp.halifax.rwth-aachen.de|137.226.34.46|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 362536 (354K) [application/octet-stream]
Saving to: '/usr/portage/distfiles/scrub-2.6.1.tar.gz.__download__'
 
/usr/portage/distfiles/scrub-2.6.1.tar.gz.__download__             100%[==============================================================================================================================================================>] 354.04K  --.-KB/s    in 0.08s   
 
2019-06-03 16:42:58 (4.24 MB/s) - '/usr/portage/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

Questo dovrebbe scaricare e spacchettare il codice sorgente. In qualche raro caso il pacchetto dovrebbe funzionare e non sono necessarie ulteriori aggiustamenti nell'ebuild

For some exceptionally simple packages like this one, that do not need patching or other more advanced treatment, the ebuild may work just so - with no further adjustments needed.

For best practice, the test suite may be run at this stage - this is particularly true when starting out:

root #ebuild scrub-2.6.1.ebuild clean test install

To actually install the new ebuild on the system, run:

root #ebuild scrub-2.6.1.ebuild clean install merge

Patching

Il patch sarà quindi elencato in un array chiamato PATCHES come è spiegato nel devmanual.

CODE Patches saranno applicate durante il src_prepare
PATCHES=(
	"${FILESDIR}"/${P}-foo.patch
	"${FILESDIR}"/${P}-bar.patch
)
 
src_prepare() {
    default
    ...
}

QA testing

Use pkgcheck (dev-util/pkgcheck) to check for QA errors in an ebuild:

user $pkgcheck scan

Vedere anche

Risorse esterne

Retrieved from "https://wiki.gentoo.org/index.php?title=Basic_guide_to_write_Gentoo_Ebuilds/it&oldid=1268819"