Usando Devtools en Arch Linux

• Compilando usando Devtools
• Archivos de configuración de Devtools
• Repositorio local
• Paquete más rápido

El paquete Devtools se creó originalmente para usuarios de confianza para crear correctamente paquetes para los repositorios oficiales. Sin embargo, también puede ser utilizado por usuarios comunes para construir paquetes AUR, o incluso paquetes oficiales modificados.

Consulte esta guía para comprender y utilizar el AUR en general, incluida la obtención del PKGBUILD. Este documento solo muestra los pasos específicos de Devtools, si es el método que elige para compilar un paquete.

Devtools mantiene una instalación de Arch limpia y separada, ubicada en /var/lib/archbuild/<TARGET>/root, que solo contiene grupos de paquetes basey base-devel. Si esta instalación limpia no existe, la crea automáticamente. Si existe, actualiza automáticamente cualquier paquete que contenga. Cuando Devtools se usa para construir un paquete, comienza con una copia de esta instalación limpia, instala los paquetes requeridos solo en la copia, copia el código fuente en ella, realiza la compilación y el empaquetado en ella, y solo copia el paquete resultante, en forma idéntica a la que se encuentra en los repositorios oficiales.

Devtools tiene ventajas sobre la ejecución makepkgdirecta. Una ventaja es que base-devely otros paquetes necesarios para compilar, pero no ejecutar, el paquete que está haciendo nunca termina en su sistema principal. Eso es menos paquetes para tener que actualizar periódicamente y preocuparse. Aunque es principalmente un beneficio para los mantenedores de paquetes de Arch, este proceso expone fácilmente cuando a PKGBUILDes incorrecto, como si se omite una dependencia de la lista que el mantenedor ya ha instalado en su sistema principal. También puede usar una máquina que sea más rápida en la creación de paquetes y copiar el paquete resultante en una máquina más lenta que lo ejecutará, sin contaminar la instalación de la máquina de construcción.

La principal desventaja es que la raíz limpia siempre está ahí, ocupando aproximadamente 800 MB, y generalmente una sola copia ocupa más espacio. Tenga en cuenta que si /var/lib/archbuild/usa Btrfs, la copia de la raíz limpia comienza siendo una instantánea de Btrfs, por lo que esos archivos no ocupan el doble de espacio. La raíz limpia siempre se mantiene allí para evitar volver a instalarla cada vez que se realiza un paquete.

Compilando usando Devtools

Instalar Devtools:

# pacman -S devtools

Para crear un paquete, Devtools incluye archbuild, pero no ejecuta esto directamente. También incluye enlaces simbólicos de {extra, gnome-unstable, kde-unstable, staging, testing}-x86_64-build. El enlace simbólico que se está utilizando para ejecutarlo será inspeccionado por archbuild, para determinar qué objetivo desea que use. Se puede ejecutar para usar estos repositorios inestables / de ensayo / prueba, que pueden tener versiones más nuevas que las que se han lanzado a los repositorios oficiales. Para utilizar los repositorios oficiales para paquetes que no sean AUR, en el directorio con PKGBUILD, por ejemplo, el directorio creado por git clone, ejecute lo siguiente:

$ extra-x86_64-build

Nota: El resto de esta guía simplemente se referirá extra-x86_64-build.

Una vez que termine de ejecutarse, los siguientes serán los resultados:

• /var/lib/archbuild/extra-x86_64/root- Un chroot limpio , que es una instalación actualizada con solo grupos de paquetes basey base-devel.
• /var/lib/archbuild/extra-x86_64/<USERNAME>- Esto contendrá un chroot de compilación . Esta es una copia del chroot limpio con las dependencias necesarias para compilar o ejecutar el paquete que se está construyendo, así como su código fuente, resultados de compilación y paquete.
• El directorio en el que se encuentra contendrá el paquete y los archivos de registro de compilación, así como cualquier código fuente descargado.

Al final, puede observar " Checking PKGBUILD" y " Checking <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz". Cualquier línea después de esto se genera namcap, que busca automáticamente problemas como PKGBUILDarchivos con formato incorrecto , dependencias incluidas que el paquete no parece usar, dependencias no incluidas que el paquete parece usar, y más. Los falsos positivos a menudo son generados por namcap, pero es una gran herramienta para dar cosas para investigar. Si su paquete funciona correctamente, no es una buena idea alertar al mantenedor sobre la namcapsalida, a menos que lo haya examinado y verificado que se debe realizar un cambio.

Puede usar pacmanpara instalar el paquete, que instalará las dependencias necesarias para ejecutar el paquete siempre que estén en repositorios oficiales o en un repositorio local.

Utilice un repositorio local como se explica aquí o instale el archivo directamente:

# pacman -U <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz

Si tuviera que ejecutar de extra-x86_64-buildnuevo, ahora mismo, o en cualquier momento posterior con este u otro paquete, actualizará el chroot limpio si es necesario, eliminará el chroot de compilación y lo convertirá en una copia nueva del chroot limpio, y realizará el mismo proceso. Si su directorio todavía tiene el código fuente descargado desde la última vez, lo usará. Si el paquete es un paquete de desarrollo AUR, extraerá nuevos cambios en lugar de volver a clonar.

Internamente, se extra-x86_64-buildejecuta makechrootpkg, que internamente llama makepkg. Las opciones para extra-x86_64-buildincluir lo siguiente:

• -c: Limpie los chroots, eliminando y recreando todo el /var/lib/archbuild/extra-x86_64/directorio, incluido su chroot limpio y todos los directorios de construcción de chroot. Esto rara vez es necesario, solo si el chroot limpio se corrompe, o si Devtools se actualiza de una manera que rompe la compatibilidad con versiones anteriores.
• -r <dir>: Use un directorio diferente al /var/lib/archbuild/extra-x86_64/que contiene los chroots.

Any arguments to extra-x86_64-build after -- are passed to makechrootpkg, when it internally uses it. Several arguments are always automatically passed from extra-x86_64-build to makechrootpkg. These automatic arguments are -r <value given to extra-x86_64-build -r option if given, /var/lib/archbuild/extra-x86_64 otherwise> -c -n. They tell makechrootpkg to remove the build chroot and make it a fresh copy of the clean chroot, and to run namcap on the package if it successfully builds. A commonly used option that can be passed to makechrootpkg is -l <copy name>. This is the directory name to give the build chroot, instead of <USERNAME>, which is useful for maintaining multiple copies or compiling multiple packages at the same time.

Any arguments to makechrootpkg after -- are passed to makepkg, when it internally uses it to build the package. The first time makepkg is run by makechrootpkg, it is done with its own unchangeable options, to download source files, if needed, and perform integrity checks; thus nothing can be forwarded on this run. It runs makepkg a second time to build the package, and always automatically passes makepkg arguments of --syncdeps --noconfirm --log --holdver --skipinteg which tells makepkg to, within the build chroot, automatically install missing dependencies required for building and using the package, not to ask for confirmation during pacman, log the build process to text files in addition to stdout, don't update source code if in a version control system and don't perform source file verification checks.

You can chain these together by using the following form:

$ extra-x86_64-build <DEVTOOLS-OPTIONS> -- <MAKECHROOTPKG-OPTIONS> -- <MAKEPKG-OPTIONS>

Note that /var/lib/archbuild can be treated as if it were a temporary directory. If you have multiple Vultr hard drives, it is worthwhile to mount a RAID0 (stripe) filesystem here. If you have a lot of RAM, you can also mount a RAM backed file-system like tmpfs. After a package is built, it's copied out into the directory you ran extra-x86_64-build from and if you wanted to, at this point you could delete /var/lib/archbuild. The next run would be slower, because it would need to make a new clean root. Alternatively, you could delete /var/lib/archbuild/<USERNAME> to reclaim extra space from the build chroot before it is automatically deleted by the next run of Devtools. So, even if you had a RAID0 filesystem mounted here fail, the most you would lose would be a compilation in process.

Devtools Configuration Files

There are a few specifics to note with Devtools configuration files. They are located in /usr/share/devtools/, such as makepkg-x86_64.conf and pacman-extra.conf:

• For /etc files like makepkg.conf and pacman.conf, you can safely edit them in place, and when the package is upgraded, it won't overwrite your changes. Rather it will save the new configuration files (if they changed from the previous version) ending with .pacnew. However, Devtools configuration files are in /usr/share/ which is not intended to be user edited, so when Devtools is upgraded, it will completely overwrite your changes to these files without alerting you. A change to this behavior has been proposed and rejected, because this helps ensure packages are sent to the official repositories all with the same compilation settings.
• The value for MAKEFLAGS, PACKAGER, and {SRC,SRCPKG,PKG,LOG}DEST are taken from /etc/makepkg.conf rather than /usr/share/devtools/makepkg-x86_64.conf.

Local Repository

If you are building packages that have dependencies on other packages you've built, you need to use a local repository, so that when pacman runs within the build chroot, it finds the dependencies.

To setup a local repository, refer to this guide's "Local Repository" section.

Create a custom target:

# ln -s archbuild /usr/bin/custom-x86_64-build
# cp /usr/share/devtools/pacman-{extra,custom}.conf

Edit /usr/share/devtools/pacman-custom.conf, and add the following at the end:

[archLocalRepo]
SigLevel = Optional TrustAll
Server = file:///archLocalRepo

Edit /etc/pacman.conf, and add the following. This forces the directory to be bind mounted in the chroot:

CacheDir    = /var/cache/pacman/pkg/ /archLocalRepo/

Now, instead of using extra-x86_64-build use this:

$ custom-x86_64-build

If you always want to use the custom target, you can delete the /var/lib/archbuild/extra-x86_64-build/ directory if it exists, as the chroots will now be in /var/lib/archbuild/custom-x86_64-build/.

Package Faster

Note enabling threaded packaging involves editing the /usr/share/devtools configuration files, which isn't officially supported, so you'll need to perform this change each time Devtools is upgraded.

Devtools combines an entire package into an archive format. By default, it makes a .tar.xz using a single thread for the xz compression.

On multi CPU systems, you can allow xz to use multiple threads by editing /usr/share/devtools/makepkg-x86_64.conf, and change the following line:

COMPRESSXZ=(xz -c -z -)

To allow as many threads as you have virtual cores:

COMPRESSXZ=(xz -c -z - --threads=0)

To allow using multiple virtual cores, but not all of them, so as to reduce impact to overall system performance, add a specific number:

COMPRESSXZ=(xz -c -z - --threads=21)

Specifying more threads than the number of virtual cores you have will decrease performance.

If you don't mind the package file being (potentially much) larger, disable compression by editing /usr/share/devtools/makepkg-x86_64.conf, and change the following line:

PKGEXT='.pkg.tar.xz'

Change it to look like the following:

PKGEXT='.pkg.tar'