Información sobre los Portes de OpenBSD

Diferencias importantes con otros proyectos BSD

NetBSD usa el término "ports" (portes) para definir a las diferentes arquitecturas en las que funciona el sistema operativo. Su estructura de portes se llama "packages" (paquetes).

Temas genéricos de infraestructura

En OpenBSD, 'make' tiene soporte para ${VAR:U} y ${VAR:L} para transformar el valor de una variable a mayúsculas o minúsculas. De acuerdo con esto, las comprobaciones de 'make' se deberían codificar de forma independiente del caso, v.g.:

	.if ${NEED_XXX:L} == "yes"
	do stuff if yes
	.else
	do other stuff
	.endif

Existe una tendencia a asegurarse que todas las variables reconocidas por bsd.port.mk se encuentren siempre definidas, de modo que al final podamos quitarnos de encima defined(GNU_GMAKE) y usar ${GNU_GMAKE:L} != "no" en su lugar.

El fichero principal bsd.port.mk ha sido fuertemente adaptado y se han solucionado algunos problemas. En particular, está preparado para ir paralelo a 'make'. La funcionalidad scripts/{pre,do,post}-* se ha perdido en el proceso. Para reemplazar esta funcionalidad, invoque el guión ("script") a mano desde el fichero Makefile.

Usar make correctamente

Note que si invoca 'make' como make VAR=value, la asignación anulará cualquier valor que VAR obtenga de Makefile. Por ello, muchos parches para Makefile no son necesarios, es mucho mejor configurar correctamente MAKE_FLAGS para disminuir la carga del mantenimiento.

Obtener el código fuente

Existen dos tipos de archivos de fuentes: DISTFILES y PATCHFILES. OpenBSD los procesa de un modo uniforme y, de modo predeterminado, lo saca todo de MASTER_SITES. No hay PATCH_SITES ni PATCH_SITES_SUBDIR.

Si todos los parches que se bajaran no provinieran del mismo grupo de sitios, OpenBSD permitiría las extensiones filename:0 a filename:9, en cuyo caso usaría MASTER_SITES0 hasta MASTER_SITES9 para bajar el fichero.

Es posible que algunas arquitecturas necesiten ficheros distfiles específicos. En el pasado, esto ha causado problemas en donde ha sido preciso replicar ("mirror") distfiles. OpenBSD dispone de soporte para un tercer grupo de ficheros: SUPDISTFILES. Éstos serán considerados sólo para generar sumas de comprobación y réplicas. Nótese que es posible que SUPDISTFILES coincida en parte con DISTFILES o PATCHFILES. Por ejemplo:

	DISTFILES=foo-1.0.tgz
	.if ${ARCH} == "i386"
	DISTFILES+=foo-i386.tgz
	.elif ${ARCHI} == "sparc"
	DISTFILES+=foo-sparc.tgz
	.endif
	SUPDISTFILES=foo-i386.tgz foo-sparc.tgz

La infraestructura de trabajo workdir

No queremos portes que usen NO_WRKDIR. Todos los portes de OpenBSD deben tener un directorio de trabajo. Los detalles sobre el nombre de estos directorios de trabajo no tienen porqué ser la preocupación de un «portador». Si necesita averiguar uno de estos nombres, mire en el fichero Makefile: cd ese_porte_dir && make show VARNAME=WRKDIR le dará una idea sobre el WRKDIR (directorio de trabajo) de ese porte.

La principal razón detrás de esa prohibición es que en OpenBSD, bsd.port.mk actúa como un fichero Makefile real, con dependencias. El paso fethc depende de los distfiles y patchfiles, y el resto de los pasos dependen de ficheros reales ubicados en el directorio de trabajo ("cookies"), así que no pueden existir sin un directorio de trabajo.

Debido a un accidente histórico, el fragmento do-extract crea el directorio de trabajo. De acuerdo con esto, pre-extract y do-extract nunca se deberían anular. Si la extracción de DISTFILES es especial, configure

EXTRACT_ONLY=

y lleve a cabo la extracción en post-extract.

WRKDIR

Directorio de trabajo del porte, en donde pone sus propios "cookies".

WRKDIST

Subdirectorio de WRKDIR, en donde el porte se desempaqueta. También es el directorio base para parches. Otros BSD no tienen en la actualidad la distinción WRKDIST/WRKSRC, y sólo tienen WRKSRC.

WRKSRC

Subdirectorio de WRKDIST, en donde están ubicados los fuentes.

WRKBUILD

Subdirectorio de WRKDIR, en donde tendrá lugar la configuración y compilación del porte. Otros BSD no tienen la distinción WRKBUILD/WRKSRC. Los programas que se basen en autoconf (la mayoría) pueden generalmente configurar SEPARATE_BUILD para dejar que la compilación del porte sea en un WRKBUILD diferente a WRKSRC.

WRKINST

Directorio en donde se instalará el porte antes de ser empaquetado (ver «Falsificación de portes», más abajo).

Nota: NO_WRKSUBDIR ha sido eliminado; su funcionalidad se puede obtener configurando WRKDIST=$(WRKDIR).

Portes falsos

Introducción

Después de que una compilación se ha completado, otros BSD proceden con la instalación del porte y a continuación compilan un paquete con el porte instalado.
En lugar de eso, OpenBSD usa una instalación falsa. Usando FAKE, el árbol de portes no se convierte del todo, pero se va aproximando.

• Un porte falso se configura y compila normalmente (v.g., para instalarse en PREFIX, que suele ser /usr/local).
• Pero se le indica que se instale en otra parte, en WRKINST, que suele ser un subdirectorio de WRKDIR.
• Entonces se empaqueta la falsa instalación, usando la opción -s de pkg_create.
• Finalmente, el paquete resultante puede ser instalado usando pkg_add.

Ventajas

• Para quien construye el paquete, esto significa que la mayoría de portes no tienen que ser instalados, lo que elimina un gran número de compromisos potenciales y desagrado general debido a portes mal instalados. También permite construir varios paquetes con conflictos entre sí en la misma máquina. Finalmente, permite construir un nuevo grupo de paquetes no probados sin tener que hacer una instalación correcta.
• Para quien construye un porte, simplifica enormemente la labor de encontrar problemas en listas de paquetes, ya que el área falsa de instalación se encuentra vacía antes de que sea instalado el porte. Además, si un porte instala demasiados ficheros, ya no es necesario retocar la instalación del porte: es suficiente con no grabar los ficheros extraños en la lista de empaquetado.
• Para el usuario final, mejora la calidad de los paquetes; ya que el porte final se instala usando pkg_add, el usuario final obtiene exactamente el mismo software que fue preparado en la máquina del portador.

Cómo hacerlo

Los objetivos invocados para make fake son los objetivos de instalación usuales, con la excepción de unas pocas diferencias:

• Se usa FAKE_FLAGS en lugar de MAKE_FLAGS. Por definición, FAKE_FLAGS configura DESTDIR=${WRKINST}.
• Se usa FAKE_TARGET en lugar de INSTALL_TARGET.
• Los fragmentos {pre,per,post}-instalación se invocan con TRUEPREFIX configurado a $(PREFIX), PREFIX configurado a $(WRKINST)$(PREFIX), y DESTDIR configurado a $(WRKINST).

Los portes que usen imake deberían funcionar tal cual, ya que los fragmentos imake están configurados para usar DESTDIR. De forma parecida, los portes recientes que usen GNU configure no deberían necesitar ningún cambio.

Otra técnica útil es un truco de `ligado tardío': configure los portes para usar un prefijo $(DESTDIR)/usr/local, de modo que el fichero Makefile resultante tenga

prefix=$(DESTDIR)/usr/local

configurado. Cuando el porte se compile, y puesto que DESTDIR está configurado a nada, se usará /usr/local y la falsa instalación pondrá todo en WRKINST/usr/local (v.g., para portes que usen GNU configure, utilice CONFIGURE_STYLE= gnu dest).

Dificultades

• Algunos portes son inconsistentes procesando sus DESTDIR: la mayoría de portes van bien con DESTDIR activado, excepto uno ó dos. Solucione el problema con parches.
• Lleve cuidado al distinguir entre la ubicación real en donde está instalado el porte, y la ubicación grabada en los ficheros de configuración del paquete. Es muy fácil saltarse esto, pero también es fácil de solucionar usando TRUEPREFIX.
• Siempre hay que retocar los enlaces simbólicos absolutos. Por suerte, bsd.port.mk se dará cuenta de los problemas en ese área.
• Unos pocos portes no quieren dejar $(DESTDIR) sólo durante la configuración. Se necesita un fragmento de postconfiguración que retoque todos los ficheros Makefile para añadir DESTDIR.
• En raras ocasiones, un porte se puede resistir a todos lo intentos razonables por usar FAKE. Una aproximación de fuerza bruta debería funcionar: use pre-fake para enlazar o copiar todo lo que el porte quiera encontrar en el área WRKINST, y entonces lleve a cabo la instalación bajo chroot.

«Sabores»

Las opciones se han racionalizado como «sabores», para que la construcción de paquetes pueda ser consistente. Un porte con opciones debe configurar FLAVORS a la lista de todas las opciones que tengan sentido para ese porte (v.g., FLAVORS=foo bar zoinx), y entonces usar FLAVOR para verificar qué opciones han sido seleccionadas (v.g., FLAVOR=zoinx foo).
bsd.port.mk provee algo de soporte:

• PKGNAME se retoca para incluir opciones separadas por guiones (v.g., package-foo-zoinx).
• WRKDIR se retoca para que se puedan compilar sabores distintos de forma concurrente sin que colisionen.
• Las construcciones de la forma %%flavor%% activarán la inclusión de PFRAG.flavor. La construcción %%SHARED%% activa la inclusión de PFRAG.shared.
• bsd.port.subdir.mk entiende la extensión SUBDIR=directory,opt1,opt2 para decir «compila el porte en directorio con FLAVOR=opt1 opt2».

Comprobar que un sabor dado ha sido seleccionado es tan simple como:

.if ${FLAVOR:L:Mzoinx}