Skip to Content
Building OsSoftware personalizado desde repositorios fuente

Software personalizado desde repositorios fuente

Las recetas OpenFactory pueden referenciar un repositorio Git como entrada de paquete personalizado en builders de imagen admitidos. Es una ruta sensible a la cadena de suministro: el repositorio, la revisión resuelta, las instrucciones de empaquetado, las dependencias de compilación y el paquete producido requieren revisión.

El soporte es específico del destino. Las compilaciones de paquetes desde fuente se rechazan en algunos builders, incluidas rutas actuales de Raspberry Pi y Proxmox. Confirma disponibilidad en la receta normalizada y el plan de compilación antes de prometer que se producirá un paquete.

Forma de la receta

Las entradas de paquetes personalizados viven bajo os.custom_packages:

{
  "os": {
    "custom_packages": [
      {
        "name": "my-agent",
        "git_url": "https://github.com/example/my-agent.git",
        "branch": "release-1.x"
      }
    ]
  }
}

El esquema acepta un nombre de rama, no un campo de commit inmutable. Para una versión controlada, registra el commit exacto resuelto por la compilación y haz de ese commit parte de la procedencia retenida. Una rama móvil sola no es entrada reproducible.

Prepara el repositorio

La ruta de empaquetado actual espera metadatos de empaquetado nativos acordes al destino. Ejemplos habituales son un directorio debian/ Debian o un spec RPM. El comportamiento exacto del builder y las versiones de destino admitidas pueden cambiar; valida un paquete mínimo en el entorno desplegado en lugar de confiar en una tabla estática de compatibilidad.

Para empaquetado Debian, revisa al menos:

  • debian/control para identidad fuente/binaria y dependencias;
  • debian/changelog para la versión del paquete;
  • debian/rules y otros scripts de mantenedor ejecutables;
  • manifiestos de instalación y unidades systemd; y
  • licencias y material de terceros incluido.

Para empaquetado RPM, revisa fuentes del spec, requisitos de compilación, scriptlets, lista de archivos y metadatos de licencia.

Nunca asumas que la propiedad del repositorio hace seguros sus scripts de compilación. Las compilaciones de paquetes ejecutan lógica de fuente y empaquetado no confiable dentro del límite de aislamiento de la infraestructura de compilación.

Otros controles de paquetes

Paquetes nativos

Usa os.packages para paquetes ya suministrados por la distribución seleccionada o un repositorio configurado explícitamente:

{
  "os": {
    "packages": ["curl", "jq"]
  }
}

Overrides de paquetes

os.package_overrides puede declarar intención add, remove o replace:

{
  "os": {
    "package_overrides": [
      {"name": "nano", "action": "replace", "replacement": "neovim"},
      {"name": "telnet", "action": "remove"}
    ]
  }
}

Un override no prueba que la resolución de dependencias lo respetara. Verifica el inventario final de paquetes y aserciones de presencia/ausencia.

Repositorios adicionales

os.extra_repos es una entrada avanzada. No añadas un repositorio HTTP sin firmar como en ejemplos antiguos. Una integración de repositorio aprobada necesita transporte HTTPS, clave de firma fijada, aplicación de firma, metadatos de release acordes al gestor de paquetes y política documentada de propiedad y actualización. Si esos controles de confianza no pueden representarse con el builder actual, no uses el repositorio.

Evidencia de aceptación

Para cada paquete personalizado, conserva:

  • URL del repositorio y commit resuelto;
  • revisión de fuente y licencia declarada;
  • instantánea del entorno de compilación y dependencias;
  • logs de compilación y nombre/versión/arquitectura del paquete resultante;
  • digest del paquete y evidencia de firma del repositorio cuando aplique;
  • inventario final de imagen que muestre el paquete instalado;
  • pruebas de humo de servicio o ejecutable; y
  • comportamiento de eliminación y actualización.

Una etapa exitosa de paquete desde fuente no basta. La compilación de imagen puede fallar después al consumir el paquete, y un paquete instalado puede seguir siendo inutilizable.

Solución de problemas

  • Metadatos de empaquetado rechazados: valida el paquete nativo localmente con la misma versión y arquitectura de distribución.
  • Dependencia de compilación faltante: usa dependencias disponibles desde repositorios aprobados para ese destino; no descargues binarios arbitrarios en silencio en un script de mantenedor.
  • Paquete ausente en la imagen: compara el nombre del paquete binario producido con la solicitud de instalación normalizada y el inventario final.
  • La versión no cambió: actualiza metadatos de versión nativos y confirma que se resolvió el nuevo commit de fuente.
  • El servicio falló: inspecciona su unidad, dependencias de runtime, permisos y logs del guest; añade una aserción a nivel de comportamiento antes de recompilar.
Imágenes baseImágenes de escritorio