
Un paquete FreeBSD normalmente especifica dependencias en su manifiesto de la siguiente manera:
deps:
# python39, version 3.9 or higher
python39: {origin: lang/python39, version: 3.9}
# bind-tools, any version
bind-tools: {origin: dns/bind-tools}
Esto hará que el administrador de paquetes verifique si ambas dependencias en la versión deseada están presentes y, si faltan, las agregará o cancelará con un error a menos que se le indique que ignore las dependencias.
Los paquetes estilo Debian (.deb) en Linux, por otro lado, ofrecen características como:
- Recomendaciones: indican al administrador de paquetes que solo ciertas características del software dependen de los paquetes enumerados como recomendados (mientras que el paquete es prácticamente inútil si falta una dependencia). Dependiendo de cómo esté configurado el administrador de paquetes, las recomendaciones pueden tratarse como dependencias o el paquete puede instalarse sin ellas.
- Alternativas: por ejemplo, un paquete puede depender de
curl | wget
, en cuyo caso la presencia de cualquiera de los paquetes por sí solo satisfará esa dependencia particular, ya que el software descubre en tiempo de ejecución cuál de los dos está instalado y funciona con lo que esté disponible.
¿.pkg también ofrece estas características? ¿Cómo se especificarían estos en el manifiesto?
Respuesta1
Los paquetes de FreeBSD son paquetes binarios (verpaquete(7)). Si bien en teoría puedes crear un paquete binario ascendente, sería muy inusual. Preferirías empezar con unpuertos(7)"puerto" basado en fuente y utilícelo como origen de su paquete. Incluso si sólo tienes una fuente binaria.
Esto está muy bien documentado en elManual del portero de FreeBSD.
Puede crear sus propios paquetes locales si lo desea. Si tiene un sistema FreeBSD básico, los paquetes binarios se instalan desde los repositorios predeterminados de FreeBSD. Todos estos paquetes están hechos del árbol de puertos con elpor defectoopciones de configuración.
Puede utilizar las herramientas de línea de comandos, pero un atajo sencillo sería explorarPuertos frescos. si miramosherramientas de enlaceVemos los siguientes valores predeterminados:
===> The following configuration options are available for bind-tools-9.18.24:
FIXED_RRSET=off: Enable fixed rrset ordering
IDN=on: International Domain Names support
JSON=on: JSON file/format/parser support
LARGE_FILE=off: 64-bit file support
====> GSSAPI Security API support: you have to select exactly one of them
GSSAPI_BASE=off: Using Heimdal in base (nsupdate is broken)
GSSAPI_HEIMDAL=off: Using security/heimdal (nsupdate is broken)
GSSAPI_MIT=off: Using security/krb5
GSSAPI_NONE=on: Disable
===> Use 'make config' to modify these settings
Entonces, si construye su puerto localmente, puede cambiar esta configuración usando make config
. Si solo quieres usarlo localmente, puedes hacer un archivo make install
. Pero si desea tener un paquete binario de esta variante, simplemente haga un archivo make package
.
Si está haciendo un puerto/paquete desde cero, puede ver cómo configurar elopciones de archivo make. Tenga en cuenta que también se pueden agrupar como opciones de radio (como con GSSAPI arriba).
Las dependencias compartidas comunes generalmente se manejan conUSOS MacroscomoPitón.
Históricamente hicistepuertos esclavospara manejar invariantes. Pero cuanto más moderno sea el enfoque, mássabores. Esto es especialmente común conPitónpero por favor recuerda ser tan liberal en elselección de versióncomo sea posible.
La arquitectura es entonces diferente a la de Debian. No existen "recomendaciones" como tales. Preferiría crear el paquete mínimo viable y luego hacer que las dependencias opcionales se puedan seleccionar en el puerto usando opciones. Las "alternativas" se manejarán nuevamente en el puerto con opciones. Su ejemplo sería entonces con un grupo de radio para permitir curl
o wget
. Para que eso se refleje en sus paquetes binarios, deberá crear sabores.
Si desea crear su propio repositorio o está haciendo esto como parte de una canalización de CI, entonces debería echar un vistazo aPoudièreque es la misma herramienta de construcción utilizada para los repositorios oficiales.