Compare commits
8 Commits
master
...
Guia_XBPS_
| Author | SHA1 | Date |
|---|---|---|
 Tuxliban Torvalds
|
657f1c2bb7 | |
 Luis
|
f8907e0c06 | |
|
Luis
|
59a76d13ae | |
|
Luis
|
f76cc7d159 | |
|
Luis
|
f3a8f8f951 | |
|
Luis
|
3f97c95774 | |
|
Luis
|
c25c34fe53 | |
|
Tuxliban Torvalds
|
76d33ee3ab |
|
|
@ -0,0 +1,324 @@
|
|||
# **Guía de uso de *xbps-src* para la construcción de paquetes**
|
||||
|
||||
## Autores
|
||||
|
||||
### Telegram
|
||||
|
||||
* @lumaro Luis
|
||||
* @tenshalito Tuxliban Torvalds
|
||||
* [Grupo de Void Linux en español](https://t.me/voidlinux_es)
|
||||
|
||||
-----
|
||||
|
||||
## **ÍNDICE**
|
||||
|
||||
-----
|
||||
|
||||
### Introducción
|
||||
|
||||
Es el generador de paquetes XBPS, escrito desde cero, que crea el software en contenedores mediante el uso de espacios de nombres de Linux, proporciona aislamiento de procesos y montajes de enlace, no se requiere ni se permite ejecutar como root, debe ejecutarlo el usuario.
|
||||
|
||||
Además, `xbps-src` puede compilar de forma nativa o realizar una compilación cruzada para la máquina de destino y admite varias bibliotecas C (glibc y musl actualmente).
|
||||
|
||||
|
||||
### Inicio rápido
|
||||
|
||||
Clonar el repositorio git void-packages e instalar los paquetes bootstrap:
|
||||
|
||||
$ git clone --depth 1 https://github.com/void-linux/void-packages.git && cd void-packages && ./xbps-src binary-bootstrap
|
||||
|
||||
- **--depth 1:** Con este parámetro sólo descargamos del servidor git el último cambio de cada paquete, no siendo necesario descargar el historial completo para construir nuestros paquetes custom.
|
||||
- **binary-bootstrap:** el conjunto de paquetes bootstrap componen el contenedor de compilación inicial, instalándose en masterdir para crear el contenedor.
|
||||
|
||||
La configuración el entorno se establece en el archivo `etc/conf`
|
||||
|
||||
- `XBPS_ALLOW_RESTRICTED=yes` Permite construir paquetes "restringidos", normalmente del repo nonfree.
|
||||
|
||||
- `XBPS_CHROOT_CMD=uchroot` Utilidad XBPS que utiliza namespaces. Tu usuario debe estar en el grupo xbuilder y el ejecutable debe tener activado el permiso especial setgid.
|
||||
|
||||
- `XBPS_CFLAGS="-march=native -O2 -pipe"` Al añadir la opción `-march=native` se le indica al compilador que construya los binarios para la arquitectura en específico que se tiene en uso. Si se planea utilizar la compilación cruzada o construir binarios genéricos, entonces se recomienda no utilizar `-march=native`
|
||||
|
||||
- `XBPS_CXXFLAGS="$XBPS_CFLAGS}"` Corresponde a las opciones de compilación para la construcción de código C++
|
||||
|
||||
- `XBPS_LDFLAGS="${XBPS_CFLAGS}"` Corresponde a las para opciones de compilación de construcción referentes a la vinculación de código del programa (vinculación dinámica [comparten librerías] o compilación estática [un binario con todas sus dependencias incluídas])
|
||||
|
||||
- `XBPS_MAKEJOBS=$(nproc)` Con esta variable se le indica al compilador que utilice todos los *cores* disponibles. Con esta opción se ahorra significativamente tiempo en la construcción de binarios
|
||||
|
||||
- `XBPS_PKG_OPTIONS="alsa,vaapi,~dbus,~vdpau,~sndio,~jack,~libpulseaudio,~pulseaudio,~wayland"` Opciones globales de construcción, afecta a todos los paquetes que contenga dicha opción para su respectiva construcción
|
||||
|
||||
- `XBPS_PKG_OPTIONS_MKSH="static"` Opciones de construcción para un paquete en específico, siguiendo la nomenclatura XBPS_PKG_OPTIONS_<pkgname>. Esta variable tiene prioridad sobre la configuración global de paquetes
|
||||
|
||||
|
||||
### Jerarquía de directorios
|
||||
|
||||
```
|
||||
/void-packages
|
||||
|- common
|
||||
|- etc
|
||||
|- srcpkgs
|
||||
| |- xbps
|
||||
| |- template
|
||||
|
|
||||
|- hostdir
|
||||
| |- binpkgs ...
|
||||
| |- ccache ...
|
||||
| |- distcc-<arch> ...
|
||||
| |- repocache ...
|
||||
| |- sources ...
|
||||
|
|
||||
|- masterdir
|
||||
| |- builddir -> ...
|
||||
| |- destdir -> ...
|
||||
| |- host -> bind mounted from <hostdir>
|
||||
| |- void-packages -> bind mounted from <void-packages>
|
||||
```
|
||||
|
||||
- `masterdir`: directorio master para construir / e instalar paquetes como rootfs.
|
||||
|
||||
- `builddir`: directorio donde se descomprimen las fuentes de los paquetes que se van a construir.
|
||||
|
||||
- `destdir`: directorio de destino falso para instalar paquetes.
|
||||
|
||||
- `hostdir/ccache`: directorio donde se almacena la ccache si la opción XBPS_CCACHE está activada.
|
||||
|
||||
- `hostdir/distcc-<arch>`: directorio donde se almacenan los archivos distcc si la opción XBPS_DISTCC está activada.
|
||||
|
||||
- `hostdir/repocache`: directorio para almacenar paquetes binarios desde repositorios remotos.
|
||||
|
||||
- `hostdir/sources`: directorio donde se almacenas las fuentes de los paquetes.
|
||||
|
||||
- `hostdir/binpkgs`: repositorio local donde se almacenas los paquetes binarios.
|
||||
|
||||
|
||||
### Consultar la ayuda de `XBPS-SRC`
|
||||
|
||||
Ejecutando `./xbps-src -h` obtenemos una lista con todas las opciones y targets.
|
||||
|
||||
Para construir un paquete ejecutamos el siguiente comando:
|
||||
|
||||
$ ./xbps-src pkg <pkgname>
|
||||
|
||||
Una vez construido, el paquete estará disponible en `hostdir/binpkgs` o en el apropiado subdirectorio, por ejemplo `hostdir/binpkgs/nonfree`
|
||||
|
||||
Opciones de construcción del paquete
|
||||
|
||||
$ ./xbps-src show-options <pkgname>
|
||||
|
||||
Las Opciones de construcción del paquete se puede activar o desactivar (con el prefijo ~) con el flag `-o` de xbps-src:
|
||||
|
||||
```
|
||||
$ ./xbps-src -o option,option1 pkg <pkgname>
|
||||
$ ./xbps-src -o ~option,~option1 pkg <pkgname>
|
||||
$ ./xbps-src -o option,~option1,~option2 pkg <pkgname>
|
||||
```
|
||||
|
||||
Las opciones de construcción de los binarios se pueden mostrar a través de `xbps-query`:
|
||||
|
||||
$ xbps-query -R --property=build-options <pkgname>
|
||||
|
||||
> NOTA: si se ha construido un paquete con opciones personalizadas y queremos mantenerlo así, debemos congelar el paquete con `xbps-pkgdb -m hold <pkgname>`, si existe una actualización del paquete será ignorada. Una vez que el paquete está congelado, la única forma de actualizarlo será explicitarlo manualmente con `xbps-install -u <pkgname>`.
|
||||
|
||||
La lista de opciones de construción de los paquetes está definida en el archivo `common/options.description` o en la plantilla de cada paquete (template).
|
||||
|
||||
|
||||
### Instalar un paquete:
|
||||
|
||||
```
|
||||
# xbps-install --repository hostdir/binpkgs <pkgname>
|
||||
$ xbps-query --repository=hostdir/binpkgs <pkgname>
|
||||
```
|
||||
|
||||
Alternativamente podemos utilizar la herramienta `xi`, incluida en el paquete `xtools` la cual tiene en cuenta el repositorio del directorio de trabajo actual.
|
||||
|
||||
$ xi <pkgname>
|
||||
|
||||
|
||||
### Reconstruir y reinstalar paquetes locales
|
||||
|
||||
Con el parámetro `-f` podemos forzar la reconstrucción y reinstalación de un paquete existente (misma versión del mismo, no se aplica a actualizaciones)
|
||||
|
||||
./xbps-src -f pkg <pkgname> && xi -f <pkgname>
|
||||
|
||||
|
||||
### Compilación cruzada para otras arquitecturas.
|
||||
|
||||
Los targets soportados se listan con `./xbps-src -h`. Con el parámetro `-a` explicitamos el target:
|
||||
|
||||
$ ./xbps-src -a <target> pkg <pkgname>
|
||||
|
||||
|
||||
### Construir paquetes nativos para Musl C library desde Glibc:
|
||||
|
||||
Preparamos el nuevo `masterdir` para Musl:
|
||||
|
||||
$ ./xbps-src -m masterdir-x86_64-musl binary-bootstrap x86_64-musl
|
||||
|
||||
Este nuevo `masterdir` ya está preparado para construir paquete nativos para Musl:
|
||||
|
||||
$ ./xbps-src -m masterdir-x86_64-musl <pkgname>
|
||||
|
||||
|
||||
### Instalar un paquete local *.xbps:
|
||||
|
||||
Añadirlo a un repositorio local, por defecto `/path/void-packages/hostdir/binpkgs`
|
||||
|
||||
$ xbps-rindex -a *.xbps
|
||||
|
||||
Instalar un paquete
|
||||
|
||||
```
|
||||
# xbps-install --repository /path <pkgname>
|
||||
# xi <pkgname>
|
||||
```
|
||||
|
||||
> NOTA: Solo indicar el nombre del paquete.
|
||||
|
||||
Forma correcta:
|
||||
|
||||
# xbps-install --repository /path/repo/local dwm
|
||||
|
||||
Forma incorrecta
|
||||
|
||||
# xbps-install --repository /path/repo/local dwm-6.3_1.x86_64.xbps
|
||||
|
||||
Para eliminar versiones anteriores de los paquetes en tu repositorio local:
|
||||
|
||||
$ xbps-rindex -r /path/void-packages/hostdir/binpkgs
|
||||
|
||||
Para limpiar el índice del repositorio:
|
||||
|
||||
$ xbps-rindex -c
|
||||
|
||||
|
||||
### Mantenimiento y limpieza del contenedor void-packages:
|
||||
|
||||
$ ./xbps-src clean-repocache && ./xbps-src clean && ./xbps-src remove-autodeps && ./xbps-src purge-distfiles
|
||||
|
||||
- `clean-repocache`: Elimina paquetes obsoletos de `<hostdir>/repocache`.
|
||||
- `clean`: Elimina dependencias automáticas, limpia `<masterdir>/builddir` y `<masterdir>/destdir`.
|
||||
- `remove-autodeps`: Elimina todas las dependencias de paquetes que se instalaron automáticamente.
|
||||
- `purge-distfiles`: Elimina todos los distfiles obsoletos en `<hostdir>/sources`.
|
||||
|
||||
|
||||
### Compilar en RAM
|
||||
|
||||
Podemos compilar en RAM montando el directorio de construcción de paquetes, ganando velocidad y evitando el desgaste de discos SSD. Debemos tener en cuenta de tener libre la cantidad de RAM suficiente para albergar las fuentes descomprimidas del paquete y la ejecución de los procesos, con paquetes pequeños no deberíamos tener problemas, ya para paquetes como Firefox o Rust, las exigengias son mayores.
|
||||
|
||||
De forma temporal:
|
||||
|
||||
# mount -t tmpfs tmpfs /path/void-packages/masterdir/builddir
|
||||
|
||||
De forma permanente en /etc/fstab, añadiendo lo siguiente:
|
||||
|
||||
tmpfs /path/void-packages/masterdir/builddir tmpfs defaults,noatime,size=16G 0 0
|
||||
|
||||
|
||||
### Kernel custom
|
||||
|
||||
A modo de ejemplo vamos a compilar un kernel custom. Con este paquete debemos controlar varias acciones simultáneamente, desde extraer fuentes y configurarlas, hasta aplicar parches personalizados, construir el paquete e intalarlo.
|
||||
|
||||
Void gestiona el kernel de manera diferente, normalmente cuando vamos a compilar un kernel custom estamos acostumbrados a descargar el último tarball desde [kernel.org](https://kernel.org/), descompimir, configurar y compilar ... esto no siempre es así, vamos a ver con detalle cómo es el proceso en Void Linux y cómo gestionarlo con XBPS-SRC.
|
||||
|
||||
Tal y como podemos observar en la plantilla de construcción del kernel, vemos que descarga el tarball y los parches para la versión de punto en curso, es decir, para obtener el último kernel a fecha que escribo este texto, el 5.17.9, baja el tarball de la serie 5.17 y luego todos los parches hasta obtener la versión de punto. Veamos esto con detalle en el template:
|
||||
|
||||
```
|
||||
pkgname=linux5.17
|
||||
version=5.17.9
|
||||
...
|
||||
distfiles="https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-${version%.*}.tar.xz
|
||||
https://cdn.kernel.org/pub/linux/kernel/v5.x/patch-${version}.xz"
|
||||
...
|
||||
skip_extraction="patch-${version}.xz"
|
||||
```
|
||||
|
||||
Aquí tenemos la descarga de la versíón del tarball 5.17 (`_linux-${version%.*_}.tar.xz`) y los parches de la versión 5.17.9 (`patch-${version}.xz`). Es muy importante fijarse y tener en cuenta esto, al igual que el valor de la variable `skip_extraction="patch-${version}.xz"` la cual indica que los parches no serán aplicados con el comando `extract`, por lo que para extraer una fuente completa del kernel, aplicando los parches de la versión de punto, en este caso 5.17.9, debemos emplear `patch`, que extrae la fuente pero no sólo realizando el `fetch` como `extract`, sino que además aplica los parches llegando a la fase `patch`, es un paso más. Veamos un ejemplo:
|
||||
|
||||
|
||||
#### Extraer las fuentes del kernel:
|
||||
|
||||
- `./xbps-src -I extract linux5.17` => Aquí estamos extrayendo las fuentes del kernel 5.17.
|
||||
- `./xbps-src -I patch linux5.17` => Aquí estamos extrayendo el kernel 5.17 y además los parches de la versión 5.17.9, que será finalmente nuestra fuente.
|
||||
|
||||
> NOTA: Con el flag `-I` se ignora descargar las dependencias del paquete, extrayendo únicamente sus respectivas fuentes.
|
||||
|
||||
|
||||
#### Configuración:
|
||||
|
||||
Para configurar las fuentes del kernel el primer paso es acceder la directorio temporal de construcción:
|
||||
|
||||
$ cd path/to/void-packages/materdir/buildir/linux5.17
|
||||
|
||||
Ahora podemos aplicar una configuración que ya tuvieramos o realizarla desde cero, os dejo los principales comandos:
|
||||
|
||||
- `make mrproper`: elimina la configuración, puesta a cero.
|
||||
|
||||
- `make oldconfig`: aplica tu configuración a las nuevas fuentes, si hay valores nuevos que no están contemplados en tu configuración pregunta por cada uno.
|
||||
|
||||
- `make olddefconfig`: lo mismo que oldconfig, pero para cada valor nuevo no contemplado en tu configuración aplica los valores por defecto.
|
||||
|
||||
- `make defconfig`: aplica una configuración por defecto para tu arquitectura, es un buen punto de partida de carácter general.
|
||||
|
||||
- `make localmodconfig`: aplica una configuración partiendo de los módulos cargados, se pueden revisar con lsmod. Es un buen punto de partida para un configuración más personalizada.
|
||||
|
||||
- `make tinyconfig`: aplica una configuración mínima, apto para diversión extrema, requiere cierta experiencia, no para empezar.
|
||||
|
||||
|
||||
Una vez configurada la fuente, debemos copiar el archivo de configuración `.config` del directorio `/path/void-packages/masterdir/buildir/linux5.17/.config` a `/path/void-packages/srcpkgs/linux5.17/files/x86_64-dotconfig-custom`
|
||||
|
||||
El nombre debe ser éste, ya que así está definido en la plantilla donde nos viene a decir que si encuentra el fichero de configuración con éste nombre, aplicará dicha configuración personalizada en el proceso de construcción:
|
||||
|
||||
```
|
||||
...
|
||||
if [ -f ${FILESDIR}/${subarch:-$arch}-dotconfig-custom ]; then
|
||||
msg_normal "Detected a custom .config file for your arch, using it.\n"
|
||||
cp -f ${FILESDIR}/${subarch:-$arch}-dotconfig-custom .config
|
||||
make ${makejobs} ARCH=$arch ${_cross} oldconfig
|
||||
...
|
||||
```
|
||||
|
||||
#### Parches personalizados
|
||||
|
||||
Además de los parches oficiales que ya hemos visto que aplica, podemos añadir parches personalizados a nuestra fuente los cuales será aplicados automáticamente tras aplicar los parches definidos en la plantilla de construcción. Para ello deberán estar en el subdirecotrio `patches` dentro del directorio del paquete, en este caso `linux5.17`:
|
||||
|
||||
```
|
||||
linux5.17
|
||||
├── files
|
||||
│ ├── arm64-dotconfig
|
||||
│ ├── i386-dotconfig
|
||||
│ ├── mv-debug
|
||||
│ ├── ppc-dotconfig
|
||||
│ ├── ppc64-dotconfig
|
||||
│ ├── ppc64le-dotconfig
|
||||
│ ├── x86_64-dotconfig
|
||||
│ └── x86_64-dotconfig-custom
|
||||
├── patches
|
||||
│ └── more-uarches-for-kernel-5.17+.patch
|
||||
└── template
|
||||
```
|
||||
|
||||
|
||||
#### Construcción e instalación del Kernel
|
||||
|
||||
Llegamos a la etapa final del kernel donde se va a compilar con todos los parches y configuraciones que se hayan aplicado y posteriormente instalarlo en el sistema. Si utilizamos `Grub` no debemos preocuparnos en ejecutar su actualización, ya que `xbps-src` se encarga de activar los `hooks` necesarios para actualizarlo tras la instalación del kernel en `/boot`.
|
||||
|
||||
$ ./xbps-src pkg linux5.17 && xi linux5.17
|
||||
|
||||
> NOTA: para recompilar y/o reinstalar la misma versión de un paquete se debe forzar, mediante el flag `-f`
|
||||
|
||||
$ ./xbps-src -f pkg linux5.17 && xi -f linux5.17
|
||||
|
||||
Llegados a este punto, con nuestra configuración ya depurada, podemos automatizar el proceso de actualización del kernel con una serie de comandos encadenados para una mayor comodidad:
|
||||
|
||||
sed -i 's/5.17.7/5.17.8/g' srcpkgs/linux5.17/template && xgensum -i linux5.17 &&./xbps-src pkg linux5.17 && xi linux5.17
|
||||
|
||||
- `sed -i` nos cambiará la versión en la plantilla, debemos especificar el valor actual y el nuevo tal y como se indica en el ejemplo.
|
||||
- `xgensum -i` nos actualizará la suma de verficación de la nueva versión del paquete.
|
||||
- `xbps-src pkg` construirá el nuevo paquete
|
||||
- `xi` nos facilitará la instalación en el sistema, forma parte del conjunto de herramientas `xtools`
|
||||
|
||||
|
||||
### Referencias
|
||||
|
||||
The XBPS source packages collection. (2022). Sitio web de Github: https://github.com/void-linux/void-packages
|
||||
|
||||
The XBPS source packages manual. (2022). Sitio web de Github: https://github.com/void-linux/void-packages/blob/master/Manual.md
|
||||
Loading…
Reference in New Issue