Results of 1 - 1 of about 98 for keyserver (0.003 sec.)
- Manual de referencia de GNU Guix
- #score: 12976
- @digest: a1f9a6e6bb5223fba5ce7f7a9673b679
- @id: 73885
- @mdate: 2019-05-19T21:18:23Z
- @size: 1961975
- @type: text/html
- content-type: text/html; charset=utf-8
- description: Manual de referencia de GNU Guix
- distribution: global
- generator: makeinfo
- keywords: Manual de referencia de GNU Guix
- resource-type: document
- #keywords: invocacion (201717), sustituciones (194614), instalacion (178600), construccion (149056), paquetes (119426), vease (86925), servicios (85713), configuracion (77715), almacen (72743), usuaria (72340), perfil (70873), preparacion (68816), usuarias (68650), construcciones (63114), salidas (60149), paquete (59175), ficheros (52446), entorno (51035), maquina (50817), indice (44479), sistema (43473), guix (41389), arranque (38812), orden (37564), distribucion (36673), fichero (35385), imagen (33836), fuentes (33524), ordenes (32214), maquinas (32084), ejecutar (31713), binarios (31537)
- Manual de referencia de GNU Guix Índice general 1 Introducción 1.1 Gestión de software con Guix 1.2 Distribución GNU 2 Instalación 2.1 Instalación binaria 2.2 Requisitos 2.3 Ejecución de la batería de pruebas 2.4 Preparación del daemon 2.4.1 Configuración del entorno de construcción 2.4.2 Uso de la facilidad de descarga de trabajo 2.4.3 Soporte de SELinux 2.4.3.1 Instalación de la política de SELinux 2.4.3.2 Limitaciones 2.5 Invocación de guix-daemon 2.6 Configuración de la aplicación 2.6.1 Localizaciones 2.6.2 Selector de servicios de nombres 2.6.3 Tipografías X11 2.6.4 Certificados X.509 2.6.5 Paquetes Emacs 2.6.6 La cadena de herramientas de GCC 3 Instalación del sistema 3.1 Limitaciones 3.2 Consideraciones sobre el hardware 3.3 Instalación desde memoria USB y DVD Copiado en una memoria USB Grabación en un DVD Arranque 3.4 Preparación para la instalación 3.5 Instalación gráfica guiada 3.6 Instalación manual 3.6.1 Distribución de teclado, red y particionado 3.6.1.1 Distribución de teclado 3.6.1.2 Red 3.6.1.3 Particionado de discos 3.6.2 Procedimiento de instalación 3.7 Tras la instalación del sistema 3.8 Instalación de Guix en una máquina virtual 3.9 Construcción de la imagen de instalación 3.10 Construcción de la imagen de instalación para placas ARM 4 Gestión de paquetes 4.1 Características 4.2 Invocación de guix package 4.3 Sustituciones 4.3.1 Servidor oficial de sustituciones. 4.3.2 Autorización de servidores de sustituciones 4.3.3 Verificación de sustituciones 4.3.4 Configuración de la pasarela. 4.3.5 Fallos en las sustituciones 4.3.6 Sobre la confianza en binarios 4.4 Paquetes con múltiples salidas 4.5 Invocación de guix gc 4.6 Invocación de guix pull 4.7 Canales 4.7.1 Uso de un canal de Guix personalizado 4.7.2 Especificación de canales adicionales 4.7.3 Declaración de dependencias de canales 4.7.4 Replicación de Guix 4.8 Inferiores 4.9 Invocación de guix describe 4.10 Invocación de guix archive 5 Desarrollo 5.1 Invocación de guix environment 5.2 Invocación de guix pack 6 Interfaz programática 6.1 Módulos de paquetes 6.2 Definición de paquetes 6.2.1 Referencia de package 6.2.2 Referencia de origin 6.3 Sistemas de construcción 6.4 El almacén 6.5 Derivaciones 6.6 La mónada del almacén 6.7 Expresiones-G 6.8 Invocación de guix repl 7 Utilidades 7.1 Invocación de guix build 7.1.1 Opciones comunes de construcción 7.1.2 Opciones de transformación de paquetes 7.1.3 Opciones de construcción adicionales 7.1.4 Depuración de fallos de construcción 7.2 Invocación de guix edit 7.3 Invocación de guix download 7.4 Invocación de guix hash 7.5 Invocación de guix import 7.6 Invocación de guix refresh 7.7 Invocación de guix lint 7.8 Invocación de guix size 7.9 Invocación de guix graph 7.10 Invocación de guix publish 7.11 Invocación de guix challenge 7.12 Invocación de guix copy 7.13 Invocación de guix container 7.14 Invocación de guix weather 7.15 Invocación de guix processes 8 Configuración del sistema 8.1 Uso de la configuración del sistema Cargador de arranque Paquetes visibles globalmente Servicios del sistema Instanciación del sistema La interfaz programática 8.2 Referencia de operating-system 8.3 Sistemas de ficheros 8.4 Dispositivos traducidos 8.5 Cuentas de usuaria 8.6 Distribución de teclado 8.7 Localizaciones 8.7.1 Consideraciones sobre la compatibilidad de datos de localización 8.8 Servicios 8.8.1 Servicios base 8.8.2 Ejecución de tareas programadas 8.8.3 Rotación del registro de mensajes 8.8.4 Servicios de red 8.8.5 Sistema X Window 8.8.6 Servicios de impresión 8.8.7 Servicios de escritorio 8.8.8 Servicios de sonido 8.8.9 Servicios de bases de datos 8.8.10 Servicios de correo 8.8.11 Servicios de mensajería 8.8.12 Servicios de telefonía 8.8.13 Servicios de monitorización 8.8.14 Servicios Kerberos 8.8.15 Servicios LDAP 8.8.16 Servicios Web 8.8.17 Servicios de certificados 8.8.18 Servicios DNS 8.8.19 Servicios VPN 8.8.20 Sistema de ficheros en red 8.8.21 Integración continua 8.8.22 Servicios de gestión de energía 8.8.23 Servicios de audio 8.8.24 Servicios de virtualización 8.8.25 Servicios de control de versiones 8.8.26 Servicios de juegos 8.8.27 Servicios misceláneos 8.8.28 Servicios de diccionario 8.9 Programas con setuid 8.10 Certificados X.509 8.11 Selector de servicios de nombres 8.12 Disco en RAM inicial 8.13 Configuración del gestor de arranque 8.14 Invocación de guix system 8.15 Ejecución de Guix en una máquina virtual 8.15.1 Conexión a través de SSH 8.15.2 Uso de virt-viewer con Spice 8.16 Definición de servicios 8.16.1 Composición de servicios 8.16.2 Tipos de servicios y servicios 8.16.3 Referencia de servicios 8.16.4 Servicios de Shepherd 9 Documentación 10 Instalación de ficheros de depuración 11 Actualizaciones de seguridad 12 Lanzamiento inicial Preparación para usar los binarios del lanzamiento inicial Construcción de las herramientas de construcción Construir los binarios de lanzamiento Reducción del conjunto de binarios de lanzamiento 13 Transportar a una nueva plataforma 14 Contribuir 14.1 Construcción desde Git 14.2 Ejecución de Guix antes de estar instalado 14.3 La configuración perfecta 14.4 Guías de empaquetamiento 14.4.1 Libertad del software 14.4.2 Nombrado de paquetes 14.4.3 Versiones numéricas 14.4.4 Sinopsis y descripciones 14.4.5 Módulos Python 14.4.5.1 Especificación de dependencias 14.4.6 Módulos Perl 14.4.7 Paquetes Java 14.4.8 Tipografías 14.5 Estilo de codificación 14.5.1 Paradigma de programación 14.5.2 Módulos 14.5.3 Tipos de datos y reconocimiento de patrones 14.5.4 Formato del código 14.6 Envío de parches Envío de una serie de parches 15 Reconocimientos Apéndice A Licencia de documentación libre GNU Índice de conceptos Índice programático Siguiente: Introducción , Subir: (dir) [ Índice general ][ Índice ] GNU Guix Este documento describe GNU Guix versión 1.0.1, una herramienta funcional de gestión de paquetes escrita para el sistema GNU. This manual is also available in Simplified Chinese (véase GNU Guix参考手册 ), French (véase Manuel de référence de GNU Guix ), German (véase Referenzhandbuch zu GNU Guix ), Spanish (véase Manual de referencia de GNU Guix ), and Russian (véase Руководство GNU Guix ). If you would like to translate it in your native language, consider joining the Translation Project . • Introducción : ¿Qué es esto de Guix? • Instalación : Instalar Guix. • Instalación del sistema : Instalar el sistema operativo completo. • Gestión de paquetes : Instalación de paquetes, actualización, etc. • Desarrollo : Desarrollo de software asistido por Guix. • Interfaz programática : Uso de Guix en Scheme. • Utilidades : Órdenes de gestión de paquetes. • Configuración del sistema : Configurar el sistema operativo. • Documentación : Navegar por los manuales de usuaria del software. • Instalación de ficheros de depuración : Alimentación del depurador. • Actualizaciones de seguridad : Desplegar correcciones de seguridad rápidamente. • Lanzamiento inicial : GNU/Linux construido de cero. • Transportar : Adaptación para otra plataforma o núcleo. • Contribuir : ¡Se necesita su ayuda! • Reconocimientos : ¡Gracias! • Licencia de documentación libre GNU : La licencia de este manual. • Índice de conceptos : Conceptos. • Índice programático : Tipos de datos, funciones y variables. — La lista detallada de nodos — Introducción • Gestión de software con Guix : Qué es especial. • Distribución GNU : Los paquetes y herramientas. Instalación • Instalación binaria : ¡Poner Guix en funcionamiento en nada de tiempo! • Requisitos : Software necesario para construir y ejecutar Guix. • Ejecución de la batería de pruebas : Probar Guix. • Preparación del daemon : Preparar el entorno del daemon de construcción. • Invocación de guix-daemon : Ejecutar el daemon de construcción. • Configuración de la aplicación : Configuración específica de la aplicación. Preparación del daemon • Configuración del entorno de construcción : Preparar el entorno aislado de construcción. • Configuración de delegación del daemon : Delegar construcciones a máquinas remotas. • Soporte de SELinux : Uso de una política SELinux para el daemon. Instalación del sistema • Limitaciones : Qué puede esperar. • Consideraciones sobre el hardware : Hardware soportado. • Instalación desde memoria USB y DVD : Preparar el medio de instalación. • Preparación para la instalación : Red, particionado, etc. • Instalación gráfica guiada : Instalación gráfica fácil. • Instalación manual : Instalación manual para artistas del teclado. • Tras la instalación del sistema : Cuando la instalación ha finalizado satisfactoriamente. • Instalación de Guix en una máquina virtual : El patio de recreo del sistema Guix. • Construcción de la imagen de instalación : Cómo esto llega a ser. Instalación manual • Distribución de teclado y red y particionado : Configuración inicial. • Procedimiento de instalación : Instalación. Gestión de paquetes • Características : Cómo Guix dará brillo a su vida. • Invocación de guix package : Instalación de paquetes, borrado, etc. • Sustituciones : Descargar binarios pre-construidos. • Paquetes con múltiples salidas : Un único paquete de fuentes, múltiples salidas. • Invocación de guix gc : Ejecutar el recolector de basura. • Invocación de guix pull : Obtener la última versión de Guix y la distribución. • Canales : Personalizar el recolector de basura. • Inferiores : Interactuar con otra revisión de Guix. • Invocación de guix describe : Muestra información acerca de su revisión de Guix. • Invocación de guix archive : Exportar e importar ficheros del almacén. Sustituciones • Servidor oficial de sustituciones. : Una fuente particular de sustituciones. • Autorización de servidores de sustituciones : Cómo activar o desactivar las sustituciones. • Verificación de sustituciones : Cómo verifica las sustituciones Guix. • Configuración de la pasarela. : Cómo obtener sustituciones a través de una pasarela. • Fallos en las sustituciones : Qué pasa cuando una sustitución falla. • Sobre la confianza en binarios : ¿Cómo puede usted confiar en esa masa informe de datos binarios? Desarrollo • Invocación de guix environment : Configurar entornos de desarrollo. • Invocación de guix pack : Creación de empaquetados de software. Interfaz programática • Módulos de paquetes : Paquetes bajo el punto de vista del programador. • Definición de paquetes : Definir nuevos paquetes. • Sistemas de construcción : Especificar como se construyen los paquetes. • El almacén : Manipular el almacén de paquetes. • Derivaciones : Interfaz de bajo nivel de las derivaciones de los paquetes. • La mónada del almacén : Interfaz puramente funcional del almacén. • Expresiones-G : Manipular expresiones de construcción. • Invocación de guix repl : Enredar con Guix interactivamente. Definición de paquetes • Referencia de «package» : El tipo de datos de los paquetes. • Referencia de «origin» : El tipo de datos de orígenes. Utilidades • Invocación de guix build : Construir paquetes desde la línea de órdenes. • Invocación de guix edit : Editar las definiciones de paquetes. • Invocación de guix download : Descargar un fichero e imprimir su hash. • Invocación de guix hash : Calcular el hash criptográfico de un fichero. • Invocación de guix import : Importar definiciones de paquetes. • Invocación de guix refresh : Actualizar definiciones de paquetes. • Invocación de guix lint : Encontrar errores en definiciones de paquetes. • Invocación de guix size : Perfilar el uso del disco. • Invocación de guix graph : Visualizar el grafo de paquetes. • Invocación de guix publish : Compartir sustituciones. • Invocación de guix challenge : Poner a prueba servidores de sustituciones. • Invocación de guix copy : Copiar a y desde un almacén remoto. • Invocación de guix container : Aislamiento de procesos. • Invocación de guix weather : Comprobar la disponibilidad de sustituciones. • Invocación de guix processes : Enumerar los procesos cliente. Invocación de guix build • Opciones comunes de construcción : Opciones de construcción para la mayoría de órdenes. • Opciones de transformación de paquetes : Crear variantes de paquetes. • Opciones de construcción adicionales : Opciones específicas de 'guix build'. • Depuración de fallos de construcción : Experiencia de empaquetamiento en la vida real. Configuración del sistema • Uso de la configuración del sistema : Personalizar su sistema GNU. • Referencia de «operating-system» : Detalle de las declaraciones de sistema operativo. • Sistemas de ficheros : Configurar el montaje de sistemas de ficheros. • Dispositivos traducidos : Procesamiento adicional de dispositivos de bloques. • Cuentas de usuaria : Especificar las cuentas de usuaria. • Distribución de teclado : Cómo interpreta el sistema las pulsaciones del teclado. • Localizaciones : Configuración de idioma y convenciones culturales. • Servicios : Especificar los servicios del sistema. • Programas con setuid : Programas que se ejecutan con privilegios de root. • Certificados X.509 : Verificar servidores HTTPS. • Selector de servicios de nombres : Configurar el selector de servicios de nombres de libc. • Disco en RAM inicial : Arranque de Linux-Libre. • Configuración del gestor de arranque : Configurar el gestor de arranque. • Invocación de guix system : Instanciar una configuración del sistema. • Ejecutar Guix en una máquina virtual : Cómo ejecutar el sistema Guix en una máquina virtual. • Definición de servicios : Añadir nuevas definiciones de servicios. Servicios • Servicios base : Servicios esenciales del sistema. • Ejecución de tareas programadas : El servicio mcron. • Rotación del registro de mensajes : El servicio rottlog. • Servicios de red : Configuración de red, daemon SSH, etc. • Sistema X Window : Interfaz gráfica. • Servicios de impresión : Soporte de impresoras locales y remotas. • Servicios de escritorio : D-Bus y servicios de escritorio. • Servicios de sonido : Servicios de ALSA y Pulseaudio. • Servicios de bases de datos : Bases de datos SQL, almacenes de clave-valor, etc. • Servicios de correo : IMAP, POP3, SMTP y todo eso. • Servicios de mensajería : Servicios de mensajería. • Servicios de telefonía : Servicios de telefonía. • Servicios de monitorización : Servicios de monitorización. • Servicios Kerberos : Servicios Kerberos. • Servicios Web : Servidores Web. • Servicios de certificados : Certificados TLS via Let's Encrypt. • Servicios DNS : Daemon de DNS. • Servicios VPN : Daemon de VPN. • Sistema de ficheros en red : Servicios relacionados con NFS. • Integración continua : El servicio Cuirass. • Servicios de gestión de energía : Extender la vida de la batería. • Servicios de audio : El MPD. • Servicios de virtualización : Servicios de virtualización. • Servicios de control de versiones : Proporcionar acceso remoto a repositorios Git. • Servicios de juegos : Servidores de juegos. • Servicios misceláneos : Otros servicios. Definición de servicios • Composición de servicios : El modelo para la composición de servicios. • Tipos de servicios y servicios : Tipos y servicios • Referencia de servicios : Referencia de la API. • Servicios de Shepherd : Un tipo de servicio particular. Siguiente: Instalación , Anterior: Top , Subir: Top [ Índice general ][ Índice ] 1 Introducción GNU Guix 1 es una herramienta de gestión de paquetes y una distribucion del sistema GNU. Guix facilita a usuarias sin privilegios la instalación, actualización o borrado de paquetes de software, la vuelta a un conjunto de paquetes previo atómicamente, la construcción de paquetes desde las fuentes, y ayuda de forma general en la creación y mantenimiento de entornos software. Puede instalar GNU Guix sobre un sistema GNU/Linux existente, donde complementará las herramientas disponibles sin interferencias (véase Instalación ), o puede usarse como un sistema operativo en sí mismo, el sistema Guix 2 . Véase Distribución GNU . • Gestión de software con Guix : Qué es especial. • Distribución GNU : Los paquetes y herramientas. Siguiente: Distribución GNU , Subir: Introducción [ Índice general ][ Índice ] 1.1 Gestión de software con Guix Guix proporciona una interfaz de gestión de paquetes de línea de ordenes (véase Gestión de paquetes ), un conjunto de utilidades de línea de órdenes (véase Utilidades ), así como interfaces programáticas Scheme (véase Interfaz programática ). Su daemon de construcción es responsable de la construcción de paquetes en delegación de las usuarias (véase Preparación del daemon ) y de la descarga de binarios preconstruidos de fuentes autorizadas (véase Sustituciones ) Guix incluye definiciones de paquetes para muchos paquetes GNU y no-GNU, todos los cuales respetan la libertad de computación de la usuaria . Es extensible : las usuarias pueden escribir sus propias definiciones de paquetes (véase Definición de paquetes ) y hacerlas disponibles como módulos independientes de paquetes (véase Módulos de paquetes ). También es personalizable : las usuarias pueden derivar definiciones de paquetes especializadas de las existentes, inclusive desde la línea de órdenes (véase Opciones de transformación de paquetes ). En su implementación, Guix utiliza la disciplina de gestión de paquetes funcional en la que Nix fue pionero (véase Reconocimientos ). En Guix, el proceso de construcción e instalación es visto como una función , en el sentido matemático. Dicha función toma entradas, como los guiones de construcción, un compilador, unas bibliotecas y devuelve el paquete instalado. Como función pura, su resultado únicamente depende de sus entradas—por ejemplo, no puede hacer referencia a software o guiones que no fuesen pasados explícitamente como entrada. Una función de construcción siempre produce el mismo resultado cuando se le proporciona un conjunto de entradas dado. No puede modificar el entorno del sistema que la ejecuta de ninguna forma; por ejemplo, no puede crear, modificar o borrar archivos fuera de sus directorios de construcción e instalación. Esto se consigue ejecutando los procesos de construcción en entornos aislados (o contenedores ), donde únicamente sus entradas explícitas son visibles. El resultado de las funciones de construcción de paquetes es almacenado en la caché en el sistema de ficheros, en un directorio especial llamado el almacén (véase El almacén ). Cada paquete se instala en un directorio propio en el almacén—por defecto, bajo /gnu/store . El nombre del directorio contiene el hash de todas las entradas usadas para construir el paquete; por tanto, cambiar una entrada resulta en un nombre de directorio distinto. Esta aproximación es el cimiento de las avanzadas características de Guix: capacidad para la actualización transaccional y vuelta-atrás de paquetes, instalación en el ámbito de la usuaria y recolección de basura de paquetes (véase Características ). Anterior: Gestión de software con Guix , Subir: Introducción [ Índice general ][ Índice ] 1.2 Distribución GNU Guix viene con una distribución del sistema GNU consistente en su totalidad de software libre 3 . La distribución puede instalarse independientemente (véase Instalación del sistema ), pero también es posible instalar Guix como un gestor de paquetes sobre un sistema GNU/Linux existente (véase Instalación ). Para distinguir entre las dos opciones, nos referimos a la distribución independiente como el sistema Guix. La distribución proporciona paquetes principales de GNU como GNU libc, GCC y Binutils, así como muchas aplicaciones GNU y no-GNU. La lista completa de paquetes disponibles se puede explorar en línea o ejecutando guix package (véase Invocación de guix package ): guix package --list-available Nuestro objetivo es proporcionar una distribución práctica con 100% software libre basada en Linux y otras variantes de GNU, con un enfoque en la promoción y la alta integración de componentes GNU, y un énfasis en programas y herramientas que ayuden a las usuarias a ejercitar esa libertad. Actualmente hay paquetes disponibles para las siguientes plataformas: x86_64-linux arquitectura x86_64 de Intel/AMD, núcleo Linux-Libre; i686-linux arquitectura de 32-bits Intel (IA32), núcleo Linux-Libre; armhf-linux arquitectura ARMv7-A con coma flotante hardware, Thumb-2 y NEON, usando la interfaz binaria de aplicaciones (ABI) EABI con coma flotante hardware, y el núcleo Linux-Libre. aarch64-linux little-endian 64-bit ARMv8-A processors, Linux-Libre kernel. mips64el-linux little-endian 64-bit MIPS processors, specifically the Loongson series, n32 ABI, and Linux-Libre kernel. This configuration is no longer fully supported; in particular, the project's build farms no longer provide substitutes for this architecture. Con el sistema Guix, declara todos los aspectos de la configuración del sistema y Guix se hace cargo de instanciar la configuración de manera transaccional, reproducible y sin estado global (véase Configuración del sistema ). El sistema Guix usa el núcleo Linux-libre, el sistema de inicialización Shepherd (véase Introducción en The GNU Shepherd Manual ), las conocidas utilidades y herramientas de compilación GNU, así como el entorno gráfico o servicios del sistema de su elección. El sistema Guix está disponible en todas las plataformas previas excepto mips64el-linux . Para información sobre el transporte a otras arquitecturas o núcleos, véase Transportar . La construcción de esta distribución es un esfuerzo cooperativo, ¡y esta invitada a unirse! Véase Contribuir , para información sobre cómo puede ayudar. Siguiente: Instalación del sistema , Anterior: Introducción , Subir: Top [ Índice general ][ Índice ] 2 Instalación Nota: Recomendamos el uso de este guión de shell de instalación para instalar Guix sobre un sistema GNU/Linux en ejecución, de aquí en adelante referido como una distribución distinta . 4 El guión automatiza la descarga, instalación y configuración inicial de Guix. Debe ejecutarse como la usuaria de administración root. Cuando está instalado sobre una distribución distinta, GNU Guix complementa las herramientas disponibles sin interferencias. Sus datos radican exclusivamente en dos directorios, normalmente /gnu/store y /var/guix ; otros ficheros en su sistema, como /etc , permanecen intactos. Una vez instalado, Guix puede ser actualizado ejecutando guix pull (véase Invocación de guix pull . Si prefiere realizar los pasos de instalación manualmente o desea personalizarlos, puede encontrar útiles las siguientes instrucciones. Describen los requisitos de software de Guix, así como su instalación manual y la preparación para su uso. • Instalación binaria : ¡Poner Guix en funcionamiento en nada de tiempo! • Requisitos : Software necesario para construir y ejecutar Guix. • Ejecución de la batería de pruebas : Probar Guix. • Preparación del daemon : Preparar el entorno del daemon de construcción. • Invocación de guix-daemon : Ejecutar el daemon de construcción. • Configuración de la aplicación : Configuración específica de la aplicación. Siguiente: Requisitos , Subir: Instalación [ Índice general ][ Índice ] 2.1 Instalación binaria Esta sección describe cómo instalar Guix en un sistema arbitrario desde un archivador autocontenido que proporciona los binarios para Guix y todas sus dependencias. Esto es normalmente más rápido que una instalación desde las fuentes, la cual es descrita en las siguientes secciones. El único requisito es tener GNU tar y Xz. Nota: Le recomendamos el uso de este guión de instalación para el shell . Automatiza la descarga, instalación y los pasos iniciales de configuración descritos a continuación. Debe ser ejecutarse como root. La instalación consiste más o menos en los siguientes pasos: Descargue el archivador con los binarios de ‘ https://ftp.gnu.org/gnu/guix/guix-binary-1.0.1. sistema .tar.xz ', donde sistema es x86_64-linux para una máquina x86_64 que ejecute el núcleo Linux, etcétera. Asegurese de descargar el fichero .sig asociado y de verificar la autenticidad del archivador con él, más o menos así: $ wget https://ftp.gnu.org/gnu/guix/guix-binary-1.0.1. sistema .tar.xz.sig $ gpg --verify guix-binary-1.0.1. sistema .tar.xz.sig Si la orden falla porque no dispone de la clave pública necesaria, entonces ejecute esta otra orden para importarla: $ gpg --keyserver pool.sks-keyservers.net \ --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 y vuelva a ejecutar la orden gpg --verify . Ahora necesita convertirse en la usuaria root . Dependiendo de su distribución, puede que tenga que ejecutar su - o sudo -i . Como root , ejecute: # cd /tmp # tar --warning=no-timestamp -xf \ guix-binary-1.0.1. sistema .tar.xz # mv var/guix /var/ && mv gnu / Esto crea /gnu/store (véase El almacén ) y /var/guix . El último contiene un perfil listo para usar para root (vea el siguiente paso). No extraiga el archivador en un sistema Guix ya funcionando ya que sobreescribiría sus propios ficheros esenciales. La opción --warning=no-timestamp asegura que GNU tar no emite avisos sobre «marcas de tiempo imposibles» (dichos avisos eran emitidos por GNU tar 1.26 y anteriores; las versiones recientes están bien). Parten del hecho de que todos los ficheros en el archivador tienen su tiempo de modificación fijado a cero (que significa el 1 de enero de 1970). Esto es hecho voluntariamente para asegurarse de que el contenido del archivador es independiente de su fecha de creación, por tanto haciendo que sea reproducible. Ponga disponible el perfil en ~root/.config/guix/current , que es donde guix pull instalará las actualizaciones (véase Invocación de guix pull ): # mkdir -p ~root/.config/guix # ln -sf /var/guix/profiles/per-user/root/current-guix \ ~root/.config/guix/current Cargue etc/profile para aumentar PATH y otras variables de entorno relevantes: # GUIX_PROFILE="`echo ~root`/.config/guix/current" ; \ source $GUIX_PROFILE/etc/profile Cree el grupo y las cuentas de usuaria para las usuarias de construcción como se explica a continuación (véase Configuración del entorno de construcción ). Ejecute el daemon, y configurelo para iniciarse automáticamente al arranque. Si su distribución anfitriona usa el sistema de inicio systemd, puede conseguirlo con estas órdenes: # cp ~root/.config/guix/current/lib/systemd/system/guix-daemon.service \ /etc/systemd/system/ # systemctl start guix-daemon && systemctl enable guix-daemon Si su distribución anfitriona usa el sistema de inicio Upstart: # initctl reload-configuration # cp ~root/.config/guix/current/lib/upstart/system/guix-daemon.conf \ /etc/init/ # start guix-daemon En otro caso, todavía puede iniciar el daemon manualmente con: # ~root/.config/guix/current/bin/guix-daemon \ --build-users-group=guixbuild Haga accesible la orden guix a otras usuarias de la máquina, por ejemplo con: # mkdir -p /usr/local/bin # cd /usr/local/bin # ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix Es también una buena idea poner disponible la versión Info de este manual ahí: # mkdir -p /usr/local/share/info # cd /usr/local/share/info # for i in /var/guix/profiles/per-user/root/current-guix/share/info/* ; do ln -s $i ; done De este modo, asumiendo que /usr/local/share/info está en la ruta de búsqueda, ejecutar info guix.es abrirá este manual (véase Other Info Directories en GNU Texinfo , para más detalles sobre cómo cambiar la ruta de búsqueda de Info). Para usar sustituciones de ci.guix.gnu.org o uno de sus espejos (véase Sustituciones ), debe autorizarlas: # guix archive --authorize < \ ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub Cada usuaria puede necesitar dar algunos pasos adicionales para prepar su entorno de Guix para el uso, véase Configuración de la aplicación . Voilà, ¡la instalación está completa! Puede confirmar que Guix está funcionando instalando un paquete de ejemplo en su perfil de root: # guix install hello El archivador de la instalación binaria puede ser (re)producido y verificado simplemente ejecutando la siguiente orden en el árbol de fuentes de Guix: make guix-binary. sistema .tar.xz ... que a su vez ejecuta: guix pack -s sistema --localstatedir \ --profile-name=current-guix guix Véase Invocación de guix pack , para más información sobre esta útil herramienta. Siguiente: Ejecución de la batería de pruebas , Anterior: Instalación binaria , Subir: Instalación [ Índice general ][ Índice ] 2.2 Requisitos Esta sección enumera los requisitos para construir Guix desde las fuentes. El procedimiento de construcción de Guix es el mismo que el de otro software GNU, y no está cubierto aquí. Por favor, eche un vistazo a los ficheros README y INSTALL en el árbol de fuentes de Guix para obtener detalles adicionales. GNU Guix está disponible para descarga desde su página web en http://www.gnu.org/software/guix/ . GNU Guix depende de los siguientes paquetes: GNU Guile , versión 2.2.x; Guile-Gcrypt , versión 0.1.0 o posterior; GnuTLS , específicamente su API para Guile (véase how to install the GnuTLS bindings for Guile en GnuTLS-Guile ); Guile-SQLite3 , versión 0.1.0 o posterior; Guile-Git , de agosto de 2017 o posterior; Guile-JSON ; zlib ; GNU Make . Las siguientes dependencias son opcionales: Las características de delegación de construcciones (véase Configuración de delegación del daemon ) y de guix copy (véase Invocación de guix copy ) dependen de Guile-SSH , versión 0.10.2 o posterior. Cuando libbz2 está disponible, guix daemon puede usarla para comprimir los log de construcción. A menos que se pasase --disable-daemon a configure , los siguientes paquetes también son necesarios: GNU libgcrypt ; SQLite 3 ; g++ de GCC con soporte para el estándar C++11 Cuando se configura Guix en un sistema que ya tiene una instalación de Guix, asegurese de especificar el mismo directorio de estado que el de la instalación existente usando la opción --localstatedir al guión configure (véase localstatedir en GNU Coding Standards ). El guión configure le proteje ante una mala configuración no deseada de localstatedir de modo que no pueda corromper inadvertidamente su almacén (véase El almacén ). Cuando está disponible una instalación en funcionamiento del gestor de paquetes Nix , puede a su vez configurar Guix con --disable-daemon . En ese caso, Nix reemplaza las tres dependencias previas. Guix es compatible con Nix, así que es posible compartir el mismo almacén entre ambos. Para hacerlo debe pasar a configure no solo el mismo valor de --with-store-dir , sino también el mismo valor de --localstatedir . El último es esencial debido a que especifica la base de datos donde se encuentran almacenados los metadatos del almacén, entre otras cosas. Los valores predeterminados para Nix son --with-store-dir=/nix/store y --localstatedir=/nix/var . Fíjese que no se requiere --disable-daemon si su objetivo es compartir el almacén con Nix. Siguiente: Preparación del daemon , Anterior: Requisitos , Subir: Instalación [ Índice general ][ Índice ] 2.3 Ejecución de la batería de pruebas Después de una ejecución exitosa de configure y make , es una buena idea ejecutar la batería de pruebas. Puede ayudar a encontrar problemas con la configuración o el entorno, o errores en el mismo Guix—e informar de fallos en las pruebas es realmente una buena forma de ayudar a mejorar el software. Para ejecutar la batería de pruebas, teclee: make check Los casos de prueba pueden ejecutarse en paralelo: puede usar la opción -j de GNU make para acelerar las cosas. La primera ejecución puede tomar algunos minutos en una máquina reciente; las siguientes ejecuciones serán más rápidas puesto que el almacén creado para las pruebas ya tendrá varias cosas en la caché. También es posible ejecutar un subconjunto de las pruebas definiendo la variable de makefile TESTS como en el ejemplo: make check TESTS="tests/store.scm tests/cpio.scm" Por defecto, los resultados de las pruebas se muestran a nivel de fichero. Para ver los detalles de cada caso de prueba individual, es posible definir la variable de makefile SCM_LOG_DRIVER_FLAGS como en el ejemplo: make check TESTS="tests/base64.scm" SCM_LOG_DRIVER_FLAGS="--brief=no" En caso de fallo, le rogamos que envíe un correo a bug-guix@gnu.org y adjunte el fichero test-suite.log . Por favor, especifique la versión de Guix usada así como los números de versión de las dependencias (véase Requisitos ) en su mensaje. Guix también viene como una batería de pruebas del sistema completo que prueban instancias completas del sistema Guix. Se puede ejecutar únicamente en sistemas donde Guix ya está instalado, usando: make check-system o, de nuevo, definiendo TESTS para seleccionar un subconjunto de las pruebas a ejecutar: make check-system TESTS="basic mcron" Estas pruebas de sistema están definidas en los módulos (gnu tests …) . Funcionan ejecutando el sistema operativo con una instrumentación ligera en una máquina virtual (VM). Pueden ser computacionalmente intensivas o bastante baratas, dependiendo de si hay sustituciones disponibles para sus dependencias (véase Sustituciones ). Algunas requieren mucho espacio de almacenamiento para alojar las imágenes de la máquina virtual. De nuevo, en caso de fallos en las pruebas, le rogamos que envíe a bug-guix@gnu.org todos los detalles. Siguiente: Invocación de guix-daemon , Anterior: Ejecución de la batería de pruebas , Subir: Instalación [ Índice general ][ Índice ] 2.4 Preparación del daemon Operaciones como la construcción de un paquete o la ejecución del recolector de basura son realizadas por un proceso especializado, el daemon de construcción , en delegación de sus clientes. Únicamente el daemon puede acceder al almacén y su base de datos asociada. Por tanto, cualquier operación que manipula el almacén se realiza a través del daemon. Por ejemplo, las herramientas de línea de órdenes como guix package y guix build se comunican con el daemon ( via llamadas a procedimientos remotos) para indicarle qué hacer. Las siguientes secciones explican cómo preparar el entorno del daemon de construcción. Véase también Sustituciones , para información sobre cómo permitir al daemon descargar binarios pre-construidos. • Configuración del entorno de construcción : Preparar el entorno aislado de construcción. • Configuración de delegación del daemon : Delegar construcciones a máquinas remotas. • Soporte de SELinux : Uso de una política SELinux para el daemon. Siguiente: Configuración de delegación del daemon , Subir: Preparación del daemon [ Índice general ][ Índice ] 2.4.1 Configuración del entorno de construcción En una configuración multiusuaria estándar, Guix y su daemon—el programa guix-daemon —son instalados por la administradora del sistema; /gnu/store pertenece a root y guix-daemon se ejecuta como root . Usuarias sin privilegios pueden usar las herramientas de Guix para construir paquetes o acceder al almacén de otro modo, y el daemon lo hará en delegación suya, asegurando que el almacén permanece en un estado consistente, y permitiendo compartir entre usuarias los paquetes construidos. Mientras que guix-daemon se ejecuta como root , puede que no desee que los procesos de construcción de paquetes se ejecuten como root también, por razones de seguridad obvias. Para evitarlo, una reserva especial de usuarias de construcción debe ser creada para ser usada por los procesos de construcción iniciados por el daemon. Estas usuarias de construcción no necesitan tener un shell ni un directorio home: simplemente serán usadas cuando el daemon se deshaga de los privilegios de root en los procesos de construcción. Tener varias de dichas usuarias permite al daemon lanzar distintos procesos de construcción bajo UID separados, lo que garantiza que no interferirán entre ellos—una característica esencial ya que las construcciones se caracterizan como funciones puras (véase Introducción ). En un sistema GNU/Linux, una reserva de usuarias de construcción puede ser creada así (usando la sintaxis de Bash y las órdenes de shadow ): # groupadd --system guixbuild # for i in `seq -w 1 10`; do useradd -g guixbuild -G guixbuild \ -d /var/empty -s `which nologin` \ -c "Usuaria de construcción Guix $i" --system \ guixbuilder$i; done El número de usuarias de construcción determina cuantos trabajos de construcción se pueden ejecutar en paralelo, especificado por la opción --max-jobs (véase --max-jobs ). Para usar guix system vm y las órdenes relacionadas, puede necesitar añadir las usuarias de construcción al grupo kvm para que puedan acceder a /dev/kvm , usando -G guixbuild,kvm en vez de -G guixbuild (véase Invocación de guix system ). El programa guix-daemon puede ser ejecutado entonces como root con la siguiente orden 5 : # guix-daemon --build-users-group=guixbuild De este modo, el daemon inicia los procesos de construcción en un “chroot”, bajo una de las usuarias guixbuilder . En GNU/Linux, por defecto, el entorno “chroot” contiene únicamente: un directorio /dev mínimo, creado en su mayor parte independientemente del /dev del sistema anfitrión 6 ; el directorio /proc ; únicamente muestra los procesos del contenedor ya que se usa un espacio de nombres de PID separado; /etc/passwd con una entrada para la usuaria actual y una entrada para la usuaria nobody ; /etc/groups con una entrada para el grupo de la usuaria; /etc/hosts con una entrada que asocia localhost a 127.0.0.1 ; un directorio /tmp con permisos de escritura. Puede influir en el directorio que el daemon utiliza para almacenar los árboles de construcción via la variable de entorno TMPDIR . No obstante, el árbol de construcción en el “chroot” siempre se llama /tmp/guix-build- nombre .drv-0 , donde nombre es el nombre de la derivación—por ejemplo, coreutils-8.24 . De este modo, el valor de TMPDIR no se escapa a los entornos de construcción, lo que evita discrepancias en caso de que los procesos de construcción capturen el nombre de su árbol de construcción. El daemon también respeta la variable de entorno http_proxy para las descargas HTTP que realiza, sea para derivaciones de salida fija (véase Derivaciones ) o para sustituciones (véase Sustituciones ). Si está instalando Guix como una usuaria sin privilegios, es posible todavía ejecutar guix-daemon siempre que pase --disable-chroot . No obstante, los procesos de construcción no estarán aislados entre sí ni del resto del sistema. Por tanto, los procesos de construcción pueden interferir entre ellos y pueden acceder a programas, bibliotecas y otros ficheros disponibles en el sistema—haciendo mucho más difícil verlos como funciones puras . Siguiente: Soporte de SELinux , Anterior: Configuración del entorno de construcción , Subir: Preparación del daemon [ Índice general ][ Índice ] 2.4.2 Uso de la facilidad de descarga de trabajo Cuando así se desee, el daemon de construcción puede delegar construcciones de derivación a otras máquinas ejecutando Guix, usando el procedimiento de extensión de construcción offload 7 . Cuando dicha característica es activada, una lista de máquinas de construcción especificadas por la usuaria es leída de /etc/guix/machines.scm ; cada vez que se solicita una construcción, por ejemplo via guix build , el daemon intenta delegarla a una de las máquinas que satisfaga las condiciones de la derivación, en particular su tipo de sistema—por ejemplo, x86_64-linux . Los prerrequisitos restantes para la construcción son copiados por SSH a la máquina objetivo, la cual procede con la construcción; con un resultado satisfactorio la(s) salida(s) de la construcción son copiadas de vuelta a la máquina inicial. El fichero /etc/guix/machines.scm normalmente tiene un contenido de este estilo: (list (build-machine (name "ochentayseis.example.org") (system "x86_64-linux") (host-key "ssh-ed25519 AAAAC3Nza…") (user "rober") (speed 2.)) ;¡increíblemente rápida! (build-machine (name "mimips.example.org") (system "mips64el-linux") (host-key "ssh-rsa AAAAB3Nza…") (user "alicia") (private-key (string-append (getenv "HOME") "/.ssh/identidad-para-guix")))) En el ejemplo anterior se especifica una lista de dos máquinas de construcción, una para la arquitectura x86_64 y otra para la arquitectura mips64el . De hecho, este fichero es—¡sin sorpresa ninguna!—un fichero Scheme que se evalúa cuando el procedimiento de extensión offload se inicia. El valor que devuelve debe ser una lista de objetos build-machine . Mientras que este ejemplo muestra una lista fija de máquinas de construcción, una puede imaginarse, digamos, el uso de DNS-SD para devolver una lista de máquinas de construcción potenciales descubierta en la red local (véase Guile-Avahi en Using Avahi in Guile Scheme Programs ). El tipo de datos build-machine se detalla a continuación. Tipo de datos: build-machine Este tipo de datos representa las máquinas de construcción a las cuales el daemon puede delegar construcciones. Los campos importantes son: name El nombre de red de la máquina remota. system El sistema de la máquina remota—por ejemplo, "x86_64-linux" . user La cuenta de usuaria a usar cuando se conecte a la máquina remota por SSH. Tenga en cuenta que el par de claves SSH no debe estar protegido por contraseña, para permitir ingresos al sistema no interactivos. host-key Este campo debe contener la clave pública de la máquina de SSH en formato OpenSSH. Es usado para autentificar la máquina cuando nos conectamos a ella. Es una cadena larga más o menos así: ssh-ed25519 AAAAC3NzaC…mde+UhL recordatorio@example.org Si la máquina está ejecutando el daemon OpenSSH, sshd , la clave pública de la máquina puede encontrarse en un fichero como /etc/ssh/ssh_host_ed25519_key.pub . Si la máquina está ejecutando el daemon SSH GNU lsh, lshd , la clave de la máquina está en /etc/lsh/host-key.pub o un fichero similar. Puede convertirse a formato OpenSSH usando lsh-export-key (véase Converting keys en LSH Manual ): $ lsh-export-key --openssh < /etc/lsh/host-key.pub ssh-rsa AAAAB3NzaC1yc2EAAAAEOp8FoQAAAQEAs1eB46LV… Ciertos número de campos opcionales pueden ser especificados: port (predeterminado: 22 ) Número de puerto del servidor SSH en la máquina. private-key (predeterminada: ~root/.ssh/id_rsa ) El fichero de clave privada SSH usado para conectarse a la máquina, en formato OpenSSH. Esta clave no debe estar protegida con una contraseña. Tenga en cuenta que el valor predeterminado es la clave privada de la cuenta de root . Asegurese de que existe si usa el valor predeterminado. compression (predeterminado: "zlib@openssh.com,zlib" ) compression-level (predeterminado: 3 ) Los métodos de compresión y nivel de compresión a nivel SSH solicitados. Tenga en cuenta que la delegación de carga depende de la compresión SSH para reducir el ancho de banda usado cuando se transfieren ficheros hacia y desde máquinas de construcción. daemon-socket (predeterminado: "/var/guix/daemon-socket/socket" ) Nombre de fichero del socket de dominio Unix en el que guix-daemon escucha en esa máquina. parallel-builds (predeterminadas: 1 ) El número de construcciones que pueden ejecutarse en paralelo en la máquina. speed (predeterminado: 1.0 ) Un «factor de velocidad relativa». El planificador de delegaciones tenderá a preferir máquinas con un factor de velocidad mayor. features (predeterminadas: '() ) Una lista de cadenas denotando las características específicas permitidas por la máquina. Un ejemplo es "kvm" para máquinas que tienen los módulos KVM de Linux y las correspondientes características hardware. Las derivaciones pueden solicitar las características por nombre, y entonces se planificarán en las máquinas adecuadas. El ejecutable guix debe estar en la ruta de búsqueda de las máquinas de construcción. Puede comprobar si es el caso ejecutando: ssh build-machine guix repl --version Hay una última cosa por hacer una vez machines.scm está en su lugar. Como se ha explicado anteriormente, cuando se delega, los ficheros se transfieren en ambas direcciones entre los almacenes de las máquinas. Para que esto funcione, primero debe generar un par de claves en cada máquina para permitir al daemon exportar los archivos firmados de ficheros en el almacén (véase Invocación de guix archive ): # guix archive --generate-key Cada máquina de construcción debe autorizar a la clave de la máquina maestra para que acepte elementos del almacén que reciba de la maestra: # guix archive --authorize < clave-publica-maestra.txt Del mismo podo, la máquina maestra debe autorizar la clave de cada máquina de construcción. Todo este lío con claves está ahí para expresar las mutuas relaciones de confianza entre pares de la máquina maestra y las máquinas de construcción. Concretamente, cuando la maestra recibe ficheros de una máquina de construcción (y vice versa ), su daemon de construcción puede asegurarse de que son genuinos, no han sido modificados, y que están firmados por una clave autorizada. Para comprobar si su configuración es operacional, ejecute esta orden en el nodo maestro: # guix offload test Esto intentará conectar con cada una de las máquinas de construcción especificadas en /etc/guix/machines.scm , comprobará que GUile y los módulos Guix están disponibles en cada máquina, intentará exportar a la máquina e importar de ella, e informará de cualquier error en el proceso. Si quiere probar un fichero de máquinas diferente, simplemente lo debe especificar en la línea de órdenes: # guix offload test otras-maquinas.scm Por último, puede probar un subconjunto de máquinas cuyos nombres coincidan con una expresión regular así: # guix offload test maquinas.scm '\.gnu\.org$' Para mostrar la carga actual de todas las máquinas de construcción, ejecute esta orden en el nodo principal: # guix offload status Anterior: Configuración de delegación del daemon , Subir: Preparación del daemon [ Índice general ][ Índice ] 2.4.3 Soporte de SELinux Guix incluye un fichero de política SELinux en etc/guix-daemon.cil que puede ser instalado en un sistema donde SELinux está activado, para etiquetar los ficheros Guix y especificar el comportamiento esperado del daemon. Ya que el sistema Guix no proporciona una política base de SELinux, la política del daemon no puede usarse en el sistema Guix. 2.4.3.1 Instalación de la política de SELinux Para instalar la política ejecute esta orden como root: semodule -i etc/guix-daemon.cil Una vez hecho, vuelva a etiquetar el sistema de ficheros con restorecon o con un mecanismo distinto que proporcione su sistema. Una vez la política está instalada, el sistema de ficheros ha sido re-etiquetado, y el daemon ha sido reiniciado, debería ejecutarse en el contexto guix_daemon_t . Puede confirmarlo con la siguiente orden: ps -Zax | grep guix-daemon Monitorice los ficheros de log de SELinux mientras ejecuta una orden como guix build hello para convencerse que SELinux permite todas las operaciones necesarias. 2.4.3.2 Limitaciones Esta política no es perfecta. Aquí está una lista de limitaciones o comportamientos extraños que deben ser considerados al desplegar la política SELinux provista para el daemon Guix. guix_daemon_socket_t no se usa realmente. Ninguna de las operaciones del socket implica contextos que tengan algo que ver con guix_daemon_socket_t . No hace daño tener esta etiqueta sin usar, pero sería preferible definir reglas del socket únicamente para esta etiqueta. guix gc no puede acceder enlaces arbitrarios a los perfiles. Por diseño, la etiqueta del fichero del destino de un enlace simbólico es independiente de la etiqueta de fichero del fichero en sí. Aunque todos los perfiles bajo $localstatedir se etiquetan, los enlaces para estos perfiles heredan la etiqueta del directorio en el que están. Para enlaces en el directorio de la usuaria esto será user_home_t . Pero para los enlaces del directorio de root, o /tmp , o del directorio del servidor HTTP, etc., esto no funcionará. guix gc se verá incapacitado para leer y seguir dichos enlaces. La característica del daemon de esperar conexiones TCP puede que no funcione más. Esto puede requerir reglas adicionales, ya que SELinux trata los sockets de red de forma diferente a los ficheros. Actualmente todos los ficheros con un nombre coincidente con la expresión regular /gnu/store.+-(gux-.+|profile)/bin/guix-daemon tienen asignada la etiqueta guix_daemon_exec_t ; esto significa que cualquier fichero con ese nombre en cualquier perfil tendrá permitida la ejecución en el dominio guix_daemon_t . Esto no es ideal. Una atacante podría construir un paquete que proporcione este ejecutable y convencer a la usuaria para instalarlo y ejecutarlo, lo que lo eleva al dominio guix_daemon_t . Llegadas a este punto, SELinux no puede prevenir que acceda a los ficheros permitidos para los procesos en dicho dominio. Podríamos generar una política mucho más restrictiva en tiempo de instalación, de modo que solo el nombre exacto del fichero del ejecutable de guix-daemon actualmente instalado sea marcado como guix_daemon_exec_t , en vez de usar una expresión regular amplia. La desventaja es que root tendría que instalar o actualizar la política en tiempo de instalación cada vez que se actualizase el paquete de Guix que proporcione el ejecutable de guix-daemon realmente en ejecución. Siguiente: Configuración de la aplicación , Anterior: Preparación del daemon , Subir: Instalación [ Índice general ][ Índice ] 2.5 Invocación de guix-daemon El programa guix-daemon implementa toda la funcionalidad para acceder al almacén. Esto incluye iniciar procesos de construcción, ejecutar el recolector de basura, comprobar la disponibilidad de un resultado de construcción, etc. Normalmente se ejecuta como root así: # guix-daemon --build-users-group=guixbuild Para detalles obre como configurarlo, véase Preparación del daemon . Por defecto, guix-daemon inicia los procesos de construcción bajo distintos UIDs, tomados del grupo de construcción especificado con --build-users-group . Además, cada proceso de construcción se ejecuta en un entorno “chroot” que únicamente contiene el subconjunto del almacén del que depende el proceso de construcción, como especifica su derivación (véase derivación ), más un conjunto específico de directorios del sistema. Por defecto, estos directorios contienen /dev y /dev/pts . Es más, sobre GNU/Linux, el entorno de construcción es un contenedor : además de tener su propio árbol del sistema de ficheros, tiene un espacio de nombres de montado separado, su propio espacio de nombres de PID, de red, etc. Esto ayuda a obtener construcciones reproducibles (véase Características ). Cuando el daemon realiza una construcción en delegación de la usuaria, crea un directorio de construcción bajo /tmp o bajo el directorio especificado por su variable de entorno TMPDIR . Este directorio se comparte con el contenedor durante toda la construcción, aunque dentro del contenedor el árbol de construcción siempre se llama /tmp/guix-build- nombre .drv-0 . El directorio de construcción se borra automáticamente una vez completado el proceso, a menos que la construcción fallase y se especificase en el cliente --keep-failed (véase --keep-failed ). El daemon espera conexiones y lanza un subproceso por sesión iniciada por cada cliente (una de las sub-órdenes de guix ). La orden guix processes le permite tener una visión general de la actividad de su sistema mostrando clientes y sesiones activas. Véase Invocación de guix processes , para más información. Se aceptan las siguientes opciones de línea de ordenes: --build-users-group= grupo Toma las usuarias de grupo para ejecutar los procesos de construcción (véase build users ). --no-substitutes No usa sustituciones para la construcción de productos. Esto es, siempre realiza las construcciones localmente en vez de permitir la descarga de binarios pre-construidos (véase Sustituciones ). Cuando el daemon se ejecuta con --no-substitutes , los clientes aún pueden activar explícitamente las sustituciones via la llamada de procedimiento remoto set-build-options (véase El almacén ). --substitute-urls= urls Considera urls la lista separada por espacios predeterminada de URLs de sustituciones de fuentes. Cuando se omite esta opción, se usa ‘ https://ci.guix.gnu.org '. Esto significa que las sustituciones puede ser descargadas de urls , mientras estén firmadas por una firma de confianza (véase Sustituciones ). --no-build-hook No usa el procedimiento de extensión de construcción . El procedimiento de extensión de construcción es un programa auxiliar que el daemon puede lanzar y al cual envía las peticiones de construcción. Este mecanismo se utiliza para delegar construcciones a otras máquinas (véase Configuración de delegación del daemon ). --cache-failures Almacena en la caché los fallos de construcción. Por defecto, únicamente las construcciones satisfactorias son almacenadas en la caché. Cuando se usa esta opción, guix gc --list-failures puede usarse para consultar el conjunto de elementos del almacén marcados como fallidos; guix gc --clear-failures borra los elementos del almacén del conjunto de fallos existentes en la caché. Véase Invocación de guix gc . --cores= n -c n Usa n núcleos de la CPU para construir cada derivación; 0 significa tantos como haya disponibles. El valor predeterminado es 0 , pero puede ser sobreescrito por los clientes, como la opción --cores de guix build (véase Invocación de guix build ). El efecto es definir la variable de entorno NIX_BUILD_CORES en el proceso de construcción, el cual puede usarla para explotar el paralelismo interno—por ejemplo, ejecutando make -j$NIX_BUILD_CORES . --max-jobs= n -M n Permite como máximo n trabajos de construcción en paralelo. El valor predeterminado es 1 . Fijarlo a 0 significa que ninguna construcción se realizará localmente; en vez de eso, el daemon delegará las construcciones (véase Configuración de delegación del daemon ), o simplemente fallará. --max-silent-time= segundos Cuando la construcción o sustitución permanece en silencio más de segundos , la finaliza e informa de un fallo de construcción. El valor predeterminado es 0 , que desactiva los plazos. El valor especificado aquí puede ser sobreescrito por clientes (véase --max-silent-time ). --timeout= segundos Del mismo modo, cuando el proceso de construcción o sustitución dura más de segundos , lo termina e informa un fallo de construcción. El valor predeterminado es 0 , que desactiva los plazos. El valor especificado aquí puede ser sobreescrito por los clientes (véase --timeout ). --rounds= N Construye cada derivación n veces seguidas, y lanza un error si los resultados de las construcciones consecutivas no son idénticos bit-a-bit. Fíjese que esta configuración puede ser sobreescrita por clientes como guix build (véase Invocación de guix build ). Cuando se usa conjuntamente con --keep-failed , la salida que difiere se mantiene en el almacén, bajo /gnu/store/…-check . Esto hace fácil buscar diferencias entre los dos resultados. --debug Produce salida de depuración. Esto es útil para depurar problemas en el arranque del daemon, pero entonces puede ser cambiado el comportamiento por los clientes, por ejemplo la opción --verbosity de guix build (véase Invocación de guix build ). --chroot-directory= dir Añade dir al chroot de construcción. Hacer esto puede cambiar el resultado del proceso de construcción—por ejemplo si usa dependencias opcionales, que se encuentren en dir , cuando están disponibles, y no de otra forma. Por esa razón, no se recomienda hacerlo. En vez de eso, asegurese que cada derivación declara todas las entradas que necesita. --disable-chroot Desactiva la construcción en un entorno «chroot». No se recomienda el uso de esta opción ya que, de nuevo, podría permitir a los procesos de construcción ganar acceso a dependencias no declaradas. Es necesario, no obstante, cuando guix-daemon se ejecuta bajo una cuenta de usuaria sin privilegios. --log-compression= tipo Comprime los logs de construcción de acuerdo a tipo , que puede ser gzip , bzip2 o none . A menos que se use --lose-logs , todos los log de construcción se mantienen en localstatedir . Para ahorrar espacio, el daemon automáticamente los comprime con bzip2 por defecto. --disable-deduplication Desactiva la «deduplicación» automática en el almacén. Por defecto, los ficheros se añaden al almacén «deduplicados» automáticamente: si un nuevo fichero añadido es idéntico a otro que ya se encuentra en el almacén, el daemon introduce el nuevo fichero como un enlace duro al otro fichero. Esto puede reducir notablemente el uso del disco, a expensas de una carga de entrada/salida ligeramente incrementada al finalizar un proceso de construcción. Esta opción desactiva dicha optimización. --gc-keep-outputs[=yes|no] Determina si el recolector de basura (GC) debe mantener salidas de las derivaciones vivas. Cuando se usa “yes”, el recolector de basura mantendrá las salidas de cualquier derivación viva disponible en el almacén—los ficheros .drv . El valor predeterminado es “no”, lo que significa que las salidas de las derivaciones se mantienen únicamente si son alcanzables desde alguna raíz del recolector de basura. Véase Invocación de guix gc , para más información sobre las raices del recolector de basura. --gc-keep-derivations[=yes|no] Determina si el recolector de basura (GC) debe mantener derivaciones correspondientes a salidas vivas. Cuando se usa “yes”, como es el caso predeterminado, el recolector de basura mantiene derivaciones—es decir, ficheros .drv —mientras al menos una de sus salidas está viva. Esto permite a las usuarias seguir la pista de los orígenes de los elementos en el almacén. El uso de “no” aquí ahorra un poco de espacio en disco. De este modo, usar --gc-keep-derivations con valor “yes” provoca que la vitalidad fluya de salidas a derivaciones, y usar --gc-keep-outputs con valor “yes” provoca que la vitalidad fluya de derivaciones a salidas. Cuando ambas tienen valor “yes”, el efecto es mantener todos los prerrequisitos de construcción (las fuentes, el compilador, las bibliotecas y otras herramientas de tiempo de construcción) de los objetos vivos del almacén, independientemente de que esos prerrequisitos sean alcanzables desde una raíz del recolector de basura. Esto es conveniente para desarrolladoras ya que ahorra reconstrucciones o descargas. --impersonate-linux-2.6 En sistemas basados en Linux, suplanta a Linux 2.6. Esto significa que la llamada del sistema uname del kernel indicará 2.6 como el número de publicación. Esto puede ser útil para construir programas que (habitualmente de forma incorrecta) dependen en el número de versión del núcleo. --lose-logs No guarda logs de construcción. Por defecto se almacenan bajo localstatedir /guix/log . --system= sistema Asume sistema como el tipo actual de sistema. Por defecto es el par de arquitectura/núcleo encontrado durante la configuración, como x86_64-linux . --listen= destino Espera conexiones en destino . destino se interpreta como el nombre del fichero del socket de dominio Unix si comienza on / (barra a la derecha). En otro caso, destino se interpreta como un nombre de máquina o un nombre de máquina y puerto a escuchar. Aquí van unos pocos ejemplos: --listen=/gnu/var/daemon Espera conexiones en el socket de dominio Unix /gnu/var/daemon , se crea si es necesario. --listen=localhost Espera conexiones TCP en la interfaz de red correspondiente a localhost , en el puerto 44146. --listen=128.0.0.42:1234 Espera conexiones TCP en la interfaz de red correspondiente a 128.0.0.42 , en el puerto 1234. Esta opción puede repetirse múltiples veces, en cuyo caso guix-daemon acepta conexiones en todos los destinos especificados. Las usuarias pueden indicar a los clientes a qué destino conectarse fijando la variable de entorno GUIX_DAEMON_SOCKET (véase GUIX_DAEMON_SOCKET ). Nota: El protocolo del daemon no está autentificado ni cifrado . El uso de --listen= dirección es aceptable en redes locales, como clusters, donde únicamente los nodos de confianza pueden conectarse al daemon de construcción. En otros casos donde el acceso remoto al daemon es necesario, recomendamos usar sockets de dominio Unix junto a SSH. Cuando se omite --listen , guix-daemon escucha conexiones en el socket de dominio Unix que se encuentra en localstatedir /guix/daemon-socket/socket . Anterior: Invocación de guix-daemon , Subir: Instalación [ Índice general ][ Índice ] 2.6 Configuración de la aplicación Cuando se usa Guix sobre una distribución GNU/Linux distinta al sistema Guix—una distribución distinta —unos pocos pasos adicionales son necesarios para tener todo preparado. Aquí están algunos de ellos. 2.6.1 Localizaciones Los paquetes instalados via Guix no usarán los datos de localización del sistema anfitrión. En vez de eso, debe primero instalar uno de los paquetes de localización disponibles con Guix y después definir la variable de entorno GUIX_LOCPATH : $ guix install glibc-locales $ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale Fíjese que el paquete glibc-locales contiene datos para todas las localizaciones que ofrece GNU libc y pesa alrededor de 110 MiB. Alternativamente, glibc-utf8-locales es más pequeño pero limitado a localizaciones UTF-8. La variable GUIX_LOCPATH juega un rol similar a LOCPATH (véase LOCPATH en The GNU C Library Reference Manual ). No obstante, hay dos diferencias importantes: GUIX_LOCPATH es respetada únicamente por la libc dentro de Guix, y no por la libc que proporcionan las distribuciones distintas. Por tanto, usar GUIX_LOCPATH le permite asegurarse de que los programas de la distribución distinta no cargarán datos de localización incompatibles. libc añade un sufijo a cada entrada de GUIX_LOCPATH con /X.Y , donde X.Y es la versión de libc—por ejemplo, 2.22 . Esto significa que, en caso que su perfil Guix contenga una mezcla de programas enlazados contra diferentes versiones de libc, cada versión de libc únicamente intentará cargar datos de localización en el formato correcto. Esto es importante porque el formato de datos de localización usado por diferentes versiones de libc puede ser incompatible. 2.6.2 Selector de servicios de nombres Cuando se usa Guix en una distribución distinta, recomendamos encarecidamente que el sistema ejecute el daemon de caché del servicio de nombres de la biblioteca de C de GNU, ncsd , que debe escuchar en el socket /var/run/nscd/socket . En caso de no hacerlo, las aplicaciones instaladas con Guix pueden fallar al buscar nombres de máquinas o cuentas de usuaria, o incluso pueden terminar abruptamente. Los siguientes párrafos explican por qué. La biblioteca de C de GNU implementa un selector de servicios de nombres (NSS), que es un mecanismo extensible para “búsquedas de nombres” en general: resolución de nombres de máquinas, cuentas de usuaria y más (véase Selector de servicios de nombres en The GNU C Library Reference Manual ). Al ser extensible, NSS permite el uso de módulos , los cuales proporcionan nuevas implementaciones de búsqueda de nombres: por ejemplo, el módulo nss-mdns permite la resolución de nombres de máquina .local , el módulo nis permite la búsqueda de cuentas de usuaria usando el servicio de información de red (NIS), etc. Estos “servicios de búsqueda” extra se configuran para todo el sistema en /etc/nsswitch.conf , y todos los programas en ejecución respetan esta configuración (véase NSS Configuration File en The GNU C Reference Manual ). Cuando se realiza una búsqueda de nombres—por ejemplo, llamando a la función getaddrinfo en C—las aplicaciones primero intentarán conectar con nscd; en caso satisfactorio, nscd realiza la búsqueda de nombres en delegación suya. Si nscd no está ejecutándose, entonces realizan la búsqueda por ellas mismas, cargando los servicios de búsqueda de nombres en su propio espacio de direcciones y ejecutándola. Estos servicios de búsqueda de nombres—los ficheros libnss_*.so —son abiertos con dlopen , pero pueden venir de la biblioteca de C del sistema, en vez de la biblioteca de C contra la que la aplicación está enlazada (la biblioteca de C que viene en Guix). Y aquí es donde está el problema: si su aplicación está enlazada contra la biblioteca de C de Guix (digamos, glibc 2.24) e intenta cargar módulos de otra biblioteca de C (digamos, libnss_mdns.so para glibc 2.22), probablemente terminará abruptamente o sus búsquedas de nombres fallarán inesperadamente. Ejecutar nscd en el sistema, entre otras ventajas, elimina este problema de incompatibilidad binaria porque esos ficheros libnss_*.so se cargan en el proceso nscd , no en la aplicación misma. 2.6.3 Tipografías X11 La mayoría de aplicaciones gráficas usan Fontconfig para encontrar y cargar tipografías y realizar la renderización del lado del cliente X11. El paquete fontconfig en Guix busca tipografías en $HOME/.guix-profile por defecto. Por tanto, para permitir a aplicaciones gráficas instaladas con Guix mostrar tipografías, tiene que instalar las tipografías también con Guix. Paquetes esenciales de tipografías incluyen gs-fonts , font-dejavu y font-gnu-freefont-ttf . Para mostrar texto escrito en lenguas chinas, Japonés o Coreano en aplicaciones gráficas, considere instalar font-adobe-source-han-sans o font-wqy-zenhei . La anterior tiene múltiples salidas, una por familia de lengua (véase Paquetes con múltiples salidas ). Por ejemplo, la siguiente orden instala tipografías para lenguas chinas: guix install font-adobe-source-han-sans:cn Programas más antiguos como xterm no usan Fontconfig sino que dependen en el lado del servidor para realizar el renderizado de tipografías. Dichos programas requieren especificar un nombre completo de tipografía usando XLFD (Descripción lógica de tipografías X), como esta: -*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1 Para ser capaz de usar estos nombres completos para las tipografías TrueType instaladas en su perfil Guix, necesita extender la ruta de fuentes del servidor X: xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir)) Después de eso, puede ejecutar xlsfonts (del paquete xlsfonts ) para asegurarse que sus tipografías TrueType se enumeran aquí. Después de instalar tipografías puede tener que refrescar la caché de tipografías para usarlas en las aplicaciones. Lo mismo aplica cuando las aplicaciones instaladas vía Guix no parecen encontrar tipografías. Para forzar la reconstrucción de la caché de tipografías ejecute fc-cache -f . La orden fc-cache es proporcionada por el paquete fontconfig . 2.6.4 Certificados X.509 El paquete nss-certs proporciona certificados X.509, que permiten a los programas verificar los servidores accedidos por HTTPS. Cuando se usa Guix en una distribución distinta, puede instalar este paquete y definir las variables de entorno relevantes de modo que los paquetes sepan dónde buscar los certificados. Véase Certificados X.509 , para información detallada. 2.6.5 Paquetes Emacs Cuando instala paquetes Emacs con Guix, los ficheros elisp pueden estar tanto en $HOME/.guix-profile/share/emacs/site-lisp/ o en subdirectorios de $HOME/.guix-profile/share/emacs/site-lisp/guix.d/ . El último directorio existe porque potencialmente pueden existir miles de paquetes Emacs, y almacenar todos sus ficheros en un directorio único puede no ser confiable (por conflictos de nombres). Por lo que pensamos que usar un directorio separado por cada paquete es una buena idea. Es muy similar a cómo el sistema de paquetes de Emacs organiza la estructura de ficheros (véase Package Files en The GNU Emacs Manual ). Por defecto, Emacs (el instalado con Guix) “sabe” donde se alojan estos paquetes, para que usted no tenga que realizar ninguna configuración. Si, por alguna razón, desea evitar la carga automática de paquetes Emacs instalados con Guix, puede hacerlo ejecutando Emacs con la opción --no-site-file (véase Init File en The GNU Emacs Manual ). 2.6.6 La cadena de herramientas de GCC Guix ofrece paquetes de compiladores individuales como gcc , pero si necesita una cadena de herramientas completa para compilar y enlazar código fuente lo que realmente desea es el paquete gcc-toolchain . Este paquete proporciona una cadena de herramientas GCC para desarrollo C/C++, incluyendo el mismo GCC, la biblioteca de C GNU (cabeceras y binarios, más símbolos de desarrollo en la salida debug ), Binutils y un recubrimiento del enlazador. El propósito del recubrimiento es inspeccionar las opciones -L y -l proporcionadas al enlazador, y los correspondientes parámetros -rpath , y llamar al enlazador real con este nuevo conjunto de parámetros. Puede instruir al recubrimiento para rechazar el enlace contra bibliotecas que no se encuentren en el almacén fijando el valor de la variable de entorno GUIX_LD_WRAPPER_ALLOW_IMPURITIES a no . Siguiente: Gestión de paquetes , Anterior: Instalación , Subir: Top [ Índice general ][ Índice ] 3 Instalación del sistema Esta sección explica cómo instalar el sistema Guix en una máquina. Guix, como gestor de paquetes, puede instalarse sobre un sistema GNU/Linux en ejecución, véase Instalación . • Limitaciones : Qué puede esperar. • Consideraciones sobre el hardware : Hardware soportado. • Instalación desde memoria USB y DVD : Preparar el medio de instalación. • Preparación para la instalación : Red, particionado, etc. • Instalación gráfica guiada : Instalación gráfica fácil. • Instalación manual : Instalación manual para artistas del teclado. • Tras la instalación del sistema : Cuando la instalación ha finalizado satisfactoriamente. • Instalación de Guix en una máquina virtual : El patio de recreo del sistema Guix. • Construcción de la imagen de instalación : Cómo esto llega a ser. Siguiente: Consideraciones sobre el hardware , Subir: Instalación del sistema [ Índice general ][ Índice ] 3.1 Limitaciones Consideramos que el sistema Guix está listo para un amplio rango de casos de uso, tanto de servidor como de escritorio. Las garantías que proporciona—actualizaciones transaccionales y vuelta atrás atómica, reproducibilidad—lo convierten en un cimiento sólido. No obstante, antes de que proceda con la instalación, sea consciente de las siguientes limitaciones apreciables que se conocen en la versión 1.0.1: No está implementada la funcionalidad del gestor de volúmenes lógicos (LVM). Se proporcionan más y más servicios del sistema (véase Servicios ), pero pueden faltar algunos. Están disponibles GNOME, Xfce, LXDE y Enlightenment (véase Servicios de escritorio ), así como un número de gestores de ventanas X11. No obstante, actualmente falta KDE. Más que una descarga de responsabilidades es una invitación a informar de problemas (¡e historias satisfactorias!), y para unirse a nosotras en su mejora. Véase Contribuir , para más información. Siguiente: Instalación desde memoria USB y DVD , Anterior: Limitaciones , Subir: Instalación del sistema [ Índice general ][ Índice ] 3.2 Consideraciones sobre el hardware GNU Guix se enfoca en respetar la libertad de computación de las usuarias. Se construye sobre el núcleo Linux-libre, lo que significa que únicamente funciona hardware para el que existen controladores y firmware libres. Hoy en día, un amplio rango del hardware común funciona con GNU/Linux-libre—desde teclados a tarjetas gráficas a escáneres y controladoras Ethernet. Desafortunadamente, todavía hay áreas donde los fabricantes de hardware deniegan a las usuarias el control de su propia computación, y dicho hardware no funciona en el sistema Guix. Una de las áreas principales donde faltan controladores o firmware libre son los dispositivos WiFi. Los dispositivos WiFi que se sabe que funcionan incluyen aquellos que usan los chips Atheros (AR9271 y AR7010), que corresponden al controlador ath9k de Linux-libre, y aquellos que usan los chips Broadcom/AirForce (BCM43xx con Wireless-Core Revisión 5), que corresponden al controlador b43-open de Linux-libre. Existe firmware libre para ambos, y está disponible por defecto en el sistema Guix, como parte de %base-firmware (véase firmware ). La Fundación del Software Libre patrocina Respeta Su Libertad (RYF), un programa de certificación para productos hardware que respetan su libertad y su privacidad y se aseguran de que usted tenga el control sobre su dispositivo. Le recomendamos que compruebe la lista de dispositivos certificados RYF. Otro recurso útil es el sitio web H-Node . Contiene un catálogo de dispositivos hardware con información acerca su funcionalidad con GNU/Linux. Siguiente: Preparación para la instalación , Anterior: Consideraciones sobre el hardware , Subir: Instalación del sistema [ Índice general ][ Índice ] 3.3 Instalación desde memoria USB y DVD Se puede descargar una imagen de instalación ISO-9660 que puede ser escrita en una memoria USB o grabada en un DVD desde ‘ https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.1. sistema .iso.xz ', donde sistema es uno de los siguientes valores: x86_64-linux para un sistema GNU/Linux en CPUs compatibles con la arquitectura de 64-bits de Intel/AMD; i686-linux para un sistema GNU/Linux en CPUs compatibles con la arquitectura de 32-bits de Intel. Asegurese de descargar el fichero .sig asociado y de verificar la autenticidad de la imagen contra él, más o menos así: $ wget https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.1. sistema .iso.xz.sig $ gpg --verify guix-system-install-1.0.1. sistema .iso.xz.sig Si la orden falla porque no dispone de la clave pública necesaria, entonces ejecute esta otra orden para importarla: $ gpg --keyserver pool.sks-keyservers.net \ --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 y vuelva a ejecutar la orden gpg --verify . Esta imagen contiene las herramientas necesarias para una instalación. Está pensada ara ser copiada tal cual a una memoria USB o DVD con espacio suficiente. Copiado en una memoria USB Para copiar la imagen en una memoria USB, siga estos pasos: Descomprima la imagen usando la orden xz : xz -d guix-system-install-1.0.1. sistema .iso.xz Conecte una memoria USB de 1 GiB o más a su máquina, y determine su nombre de dispositivo. Asumiendo que la memoria USB es /dev/sdX copie la imagen con: dd if=guix-system-install-1.0.1. sistema .iso of=/dev/sdX sync El acceso a /dev/sdX normalmente necesita privilegios de root. Grabación en un DVD Para copiar la imagen a un DVD, siga estos pasos: Descomprima la imagen usando la orden xz : xz -d guix-system-install-1.0.1. sistema .iso.xz Introduzca un DVD en su máquina para grabarlo, y determine el nombre del dispositivo. Asumiendo que la unidad DVD es /dev/srX , copie la imagen con: growisofs -dvd-compat -Z /dev/srX=guix-system-install-1.0.1. sistema .iso El acceso a /dev/srX normalmente necesita privilegios de root. Arranque Una vez hecho esto, debe ser capaz de reiniciar el sistema y arrancar desde la memoria USB o el DVD. Lo primero habitualmente requiere que introducirse en la BIOS o en el menú de arranque UEFI, donde se puede seleccionar el arranque desde la memoria USB. Véase Instalación de Guix en una máquina virtual , si, en vez de esto, desea instalar el sistema Guix en una máquina virtual (VM). Siguiente: Instalación gráfica guiada , Anterior: Instalación desde memoria USB y DVD , Subir: Instalación del sistema [ Índice general ][ Índice ] 3.4 Preparación para la instalación Una vez que haya arrancado, puede usar el instalador gráfico guiado, el cual facilita la introducción al sistema (véase Instalación gráfica guiada ). Alternativamente, si ya es está familiarizada con GNU/Linux y desea más control que el que proporciona el instalador gráfico, puede seleccionar el proceso de instalación “manual” (véase Instalación manual ). El instalador gráfico está disponible en TTY1. Puede obtener consolas de root en los TTY 3 a 6 pulsando ctrl-alt-f3 , ctrl-alt-f4 , etc. TTY2 muestra esta documentación y se puede cambiar a dicha consola con ctrl-alt-f2 . La documentación es explorable usando las órdenes del lector Info (véase Stand-alone GNU Info ). El sistema de instalación ejecuta el daemon GPM para ratones, el cual le permite seleccionar texto con el botón izquierdo y pegarlo con el botón central. Nota: La instalación requiere acceso a Internet de modo que cualquier dependencia de su configuración de sistema no encontrada pueda ser descargada. Véase la sección “Red” más adelante. Siguiente: Instalación manual , Anterior: Preparación para la instalación , Subir: Instalación del sistema [ Índice general ][ Índice ] 3.5 Instalación gráfica guiada El instalador gráfico es una interfaz de usuaria basada en texto. Le guiará, con cajas de diálogo, a través de los pasos necesarios para instalar el sistema GNU Guix. Las primeras cajas de diálogo le permiten configurar el sistema mientras lo usa durante la instalación: puede seleccionar el idioma, la distribución del teclado y configurar la red, la cual se usará durante la instalación. La siguiente imagen muestra el diálogo de configuración de red. Los siguientes pasos le permitirán particionar su disco duro, como se muestra en la siguiente imagen, elegir si se usarán o no sistemas de ficheros cifrados, introducir el nombre de la máquina, la contraseña de root y crear cuentas adicionales, entre otras cosas. Tenga en cuenta que, en cualquier momento, el instalador le permite salir de la instalación actual y retomarla en un paso previo, como se muestra en la siguiente imagen. Una vez haya finalizado, el instalador produce una configuración de sistema operativo y la muestra (véase Uso de la configuración del sistema ). En este punto puede pulsar “OK” y la instalación procederá. En caso de finalización satisfactoria, puede reiniciar con el nuevo sistema y disfrutarlo. ¡Véase Tras la instalación del sistema para ver cómo proceder a continuación! Siguiente: Tras la instalación del sistema , Anterior: Instalación gráfica guiada , Subir: Instalación del sistema [ Índice general ][ Índice ] 3.6 Instalación manual Esta sección describe como podría instalar “manualmente” el sistema GNU Guix en su máquina. Esta opción requiere familiaridad con GNU/Linux, con el shell y con las herramientas de administración comunes. Si puensa que no es para usted, considere el uso del instalador gráfico guiado (véase Instalación gráfica guiada ). El sistema de instalación proporciona consolas de root en los terminales virtuales (TTY) 3 a 6; pulse ctrl-alt-f3 , ctrl-alt-f4 y sucesivas teclas para abrirlas. Incluye muchas herramientas comunes necesarias para la instalación del sistema. Pero es también un sistema Guix completo, lo que significa que puede instalar paquetes adicionales, en caso de necesitarlos, mediante el uso de guix package (véase Invocación de guix package ). • Distribución de teclado y red y particionado : Configuración inicial. • Procedimiento de instalación : Instalación. Siguiente: Procedimiento de instalación , Subir: Instalación manual [ Índice general ][ Índice ] 3.6.1 Distribución de teclado, red y particionado Antes de instalar el sistema, puede desear ajustar la distribución del teclado, configurar la red y particionar el disco duro deseado. Esta sección le guiará durante este proceso. 3.6.1.1 Distribución de teclado La imagen de instalación usa la distribución de teclado QWERTY de los EEUU. Si desea cambiarla, puede usar la orden loadkeys . Por ejemplo, la siguiente orden selecciona la distribución de teclado para el castellano: loadkeys es Véanse los ficheros bajo /run/current-system/profile/share/keymaps para la obtención de una lista de distribuciones de teclado disponibles. Ejecute man loadkeys para más información. 3.6.1.2 Red Ejecute la siguiente orden para ver los nombres asignados a sus interfaces de red: ifconfig -a … o, usando la orden específica de GNU/Linux ip : ip a El nombre de las interfaces de cable comienza con ‘ e '; por ejemplo, la interfaz que corresponde a la primera controladora Ethernet en la placa se llama ‘ eno1 '. El nombre de las interfaces inalámbricas comienza con ‘ w ', como ‘ w1p2s0 '. Conexión por cable Para configurar una red por cable ejecute la siguiente orden, substituyendo interfaz con el nombre de la interfaz de cable que desea usar. ifconfig interfaz up Conexión sin cable Para configurar una red inalámbrica, puede crear un fichero de configuración para la herramienta de configuración wpa_supplicant (su ruta no es importante) usando uno de los editores de texto disponibles como nano : nano wpa_supplicant.conf Como un ejemplo, la siguiente plantilla puede colocarse en este fichero y funcionará para muchas redes inalámbricas, siempre que se proporcione el SSID y la contraseña reales de la red a la que se va a conectar: network={ ssid=" mi-ssid " key_mgmt=WPA-PSK psk="la contraseña de la red" } Inicie el servicio inalámbrico y ejecutelo en segundo plano con la siguiente orden (sustituya interfaz por el nombre de la interfaz de red que desea usar): wpa_supplicant -c wpa_supplicant.conf -i interfaz -B Ejecute man wpa_supplicant para más información. En este punto, necesita obtener una dirección IP. En una red donde las direcciones IP se asignan automáticamente mediante DHCP, puede ejecutar: dhclient -v interfaz Intente hacer ping a un servidor para comprobar si la red está funcionando correctamente: ping -c 3 gnu.org Configurar el acceso por red es casi siempre un requisito debido a que la imagen no contiene todo el software y las herramientas que puedan ser necesarias. Si lo desea, puede continuar la instalación de forma remota iniciando un servidor SSH: herd start ssh-daemon Asegurese de fijar una contraseña con passwd , o configurar la verificación de clave pública de OpenSSH para la introducción en el sistema. 3.6.1.3 Particionado de discos A menos que se haya realizado previamente, el siguiente paso es el particionado, y después dar formato a la/s partición/es deseadas. La imagen de instalación contiene varias herramientas de particionado, incluyendo Parted (véase Overview en GNU Parted User Manual ), fdisk y cfdisk . Ejecutelo y configure el mapa de particiones deseado en su disco: cfdisk Si su disco usa el formato de tabla de particiones GUID (GPT) y tiene pensado instalar GRUB basado en BIOS (la opción predeterminada), asegurese de tener una partición de arranque BIOS disponible (véase BIOS installation en GNU GRUB manual ). Si en vez de eso desea GRUB basado en EFI, se requiere una Partición del Sistema EFI (ESP) con formato FAT32. Esta partición puede montarse en /boot/efi y debe tener la opción esp activa. Por ejemplo, en parted : parted /dev/sda set 1 esp on Nota: ¿No esta segura si usar GRUB basado en EFI o en BIOS? Si el directorio /sys/firmware/efi existe en la imagen de instalación, probablemente debería realizar una instalación EFI, usando grub-efi-bootloader . En otro caso, debe usar GRUB basado en BIOS, conocido como grub-bootloader . Véase Configuración del gestor de arranque , para más información sobre cargadores de arranque. Una vez haya terminado con el particionado de la unidad de disco deseada, tiene que crear un sistema de ficheros en la o las particiónes relevantes 8 . Para la ESP, si tiene una y asumiendo que es /dev/sda1 , ejecute: mkfs.fat -F32 /dev/sda1 Preferentemente, asigne una etiqueta a los sistemas de ficheros de modo que pueda referirse a ellos de forma fácil y precisa en las declaraciones file-system (véase Sistemas de ficheros ). Esto se consigue habitualmente con la opción -L de mkfs.ext4 y las ordenes relacionadas. Por tanto, asumiendo que la partición de la raíz es /dev/sda2 , se puede crear un sistema de ficheros con la etiqueta mi-raiz de esta manera: mkfs.ext4 -L mi-raiz /dev/sda2 Si en vez de eso planea cifrar la partición raíz, puede usar las herramientas Crypsetup/LUKS para hacerlo (véase man cryptsetup para más información). Asumiendo que quiere almacenar la partición raíz en /dev/sda2 , la secuencia de ordenes sería más o menos así: cryptsetup luksFormat /dev/sda2 cryptsetup open --type luks /dev/sda1 mi-particion mkfs.ext4 -L mi-raiz /dev/mapper/mi-particion Una vez hecho esto, monte el sistema de ficheros deseado bajo /mnt con una orden como (de nuevo, asumiendo que mi-raiz es la etiqueta del sistema de ficheros raíz): mount LABEL=mi-raiz /mnt Monte también cualquier otro sistema de ficheros que desee usar en el sistema resultante relativamente a esta ruta. Si ha optado por /boot/efi como el punto de montaje de EFI, por ejemplo, ahora debe ser montada en /mnt/boot/efi para que guix system init pueda encontrarla más adelante. Finalmente, si planea usar una o más particiones de intercambio (véase swap space en The GNU C Library Reference Manual ), asegurese de inicializarla con mkswap . Asumiendo que tuviese una partición de intercambio en /dev/sda3 , ejecutaría: mkswap /dev/sda3 swapon /dev/sda3 De manera alternativa, puede usar un fichero de intercambio. Por ejemplo, asumiendo que en el nuevo sistema desea usar el fichero /fichero-de-intercambio como tal, ejecutaría 9 : # Esto son 10GiB de espacio de intercambio. Ajuste "count" para # cambiar el tamaño. dd if=/dev/zero of=/mnt/swapfile bs=1MiB count=10240 # Por seguridad, se le conceden permisosde lectura y escritura # únicamente a root. chmod 600 /mnt/swapfile mkswap /mnt/swapfile swapon /mnt/swapfile Fijese que si ha cifrado la partición raíz y creado un fichero de intercambio en su sistema de ficheros como se ha descrito anteriormente, el cifrado también protege al fichero de intercambio, como a cualquier fichero en dicho sistema de ficheros. Anterior: Distribución de teclado y red y particionado , Subir: Instalación manual [ Índice general ][ Índice ] 3.6.2 Procedimiento de instalación Con las particiones deseadas listas y la raíz deseada montada en /mnt , estamos preparadas para empezar. Primero, ejecute: herd start cow-store /mnt Esto activa la copia-durante-escritura en /gnu/store , de modo que los paquetes que se añadan durante la fase de instalación se escriban en el disco montado en /mnt en vez de permanecer en memoria. Esto es necesario debido a que la primera fase de la orden guix system init (vea más adelante) implica descargas o construcciones en /gnu/store , el cual, inicialmente, está un sistema de ficheros en memoria. Después debe editar un fichero y proporcionar la declaración de sistema operativo a instalar. Para dicho fin, el sistema de instalación viene con tres editores de texto. Recomendamos GNU nano (véase GNU nano Manual ), que permite el resaltado de sintaxis y correspondencia de paréntesis; los otros editores son GNU Zile (un clon de Emacs) y nvi (un clon del editor vi original de BSD). Le recomendamos encarecidamente almacenar ese fichero en el sistema de ficheros raíz, digamos, como /mnt/etc/config.scm . En caso de no hacerlo, habrá perdido su configuración del sistema una vez arranque en el sistema recién instalado. Véase Uso de la configuración del sistema , para hacerse una idea del fichero de configuración. Las configuraciones de ejemplo mencionadas en esa sección están disponibles bajo /etc/configuration en la imagen de instalación. Por tanto, para empezar con una configuración del sistema que proporcione un servidor gráfico (un sistema de “escritorio”), puede ejecutar algo parecido a estas órdenes: # mkdir /mnt/etc # cp /etc/configuration/desktop.scm /mnt/etc/config.scm # nano /mnt/etc/config.scm Debe prestar atención a lo que su fichero de configuración contiene, y en particular: Asegurese que la forma bootloader-configuration especifica la localización deseada de la instalación de GRUB. Debe mencionar grub-bootloader si está usando GRUB con el arranque antiguo, o grub-efi-bootloader para sistemas más nuevos UEFI. Para los sistemas antiguos, el campo target denomina un dispositivo, como /dev/sda ; para los sistemas UEFI denomina la ruta de una partición EFI montada, como /boot/efi ; asegurese de que la ruta está actualmente montada y haya una entrada file-system especificada en su configuración. Asegurese que las etiquetas de su sistema de ficheros corresponden con el valor de sus campos device respectivos en su configuración file-system , asumiendo que su configuración file-system usa el procedimiento file-system-label en su campo device . Si hay particiones cifradas o en RAID, asegurese de añadir un campo mapped-devices para describirlas (véase Dispositivos traducidos ). Una vez haya terminado de preparar el fichero de configuración, el nuevo sistema debe ser inicializado (recuerde que el sistema de ficheros raíz deseado está montado bajo /mnt ): guix system init /mnt/etc/config.scm /mnt Esto copia todos los ficheros necesarios e instala GRUB en /dev/sdX , a menos que proporcione la opción --no-bootloader . Para más información, véase Invocación de guix system . Esta orden puede desencadenar descargas o construcciones de paquetes no encontrados, lo cual puede tomar algún tiempo. Una vez que la orden se complete—¡y, deseablemente, de forma satisfactoria!—puede ejecutar reboot y arrancar con el nuevo sistema. La contraseña de root en el nuevo sistema está vacía inicialmente; otras contraseñas de usuarias tienen que ser inicializadas ejecutando la orden passwd como root , a menos que en su configuración se especifique de otra manera (véase contraseñas de cuentas de usuaria ). ¡Véase Tras la instalación del sistema para proceder a continuación! Siguiente: Instalación de Guix en una máquina virtual , Anterior: Instalación manual , Subir: Instalación del sistema [ Índice general ][ Índice ] 3.7 Tras la instalación del sistema ¡Éxito! ¡Ha arrancado en el sistema Guix! De ahora en adelante, puede actualizar el sistema cuando quiera mediante la ejecución de, digamos: guix pull sudo guix system reconfigure /etc/config.scm Esto construye una nueva generación del sistema con los últimos paquetes y servicios (véase Invocación de guix system ). Recomendamos realizarlo de manera regular de modo que su sistema incluya las últimas actualizaciones de seguridad (véase Actualizaciones de seguridad ). Nota: Tenga en cuenta que sudo guix ejecuta el ejecutable guix de su usuaria y no el de root, ya que sudo no altera PATH . Para ejecutar explícitamente el ejecutable guix de root, escriba sudo -i guix … . ¡Unase a nosotras en #guix en la red IRC Freenode o en guix-devel@gnu.org para compartir su experiencia! Siguiente: Construcción de la imagen de instalación , Anterior: Tras la instalación del sistema , Subir: Instalación del sistema [ Índice general ][ Índice ] 3.8 Instalación de Guix en una máquina virtual Si desea instalar el sistema Guix en una máquina virtual (VM) o en un servidor privado virtual (VPS) en vez de en su preciada máquina, esta sección es para usted. Si quiere arrancar una VM QEMU para instalar el sistema Guix en una imagen de disco, siga estos pasos: Primero, obtenga y descomprima la imagen de instalación del sistema Guix como se ha descrito previamente (véase Instalación desde memoria USB y DVD ). Cree una imagen de disco que contendrá el sistema instalado. Para crear una imagen de disco con formato qcow2, use la orden qemu-img : qemu-img create -f qcow2 guixsd.img 50G El fichero que obtenga será mucho menor de 50GB (típicamente menos de 1MB), pero crecerá cuando el dispositivo de almacenamiento virtualizado se vaya llenando. Arranque la imagen de instalación USB en una máquina virtual: qemu-system-x86_64 -m 1024 -smp 1 \ -net user -net nic,model=virtio -boot menu=on \ -drive file=guix-system-install-1.0.1. sistema .iso \ -drive file=guixsd.img El orden de las unidades importa. En la consola de la VM, pulse rápidamente la tecla F12 para entrar al menú de arranque. Pulse la tecla 2 y la tecla RET para confirmar su selección. Ahora es root en la VM, prosiga con el procedimiento de instalación. Véase Preparación para la instalación , y siga las instrucciones. Una vez complete la instalación, puede arrancar el sistema que está en la imagen guixsd.img . Véase Ejecutar Guix en una máquina virtual , para información sobre cómo hacerlo. Anterior: Instalación de Guix en una máquina virtual , Subir: Instalación del sistema [ Índice general ][ Índice ] 3.9 Construcción de la imagen de instalación La imagen de instalación descrita anteriormente se construyó usando la orden guix system , específicamente: guix system disk-image --file-system-type=iso9660 \ gnu/system/install.scm Eche un vistazo a gnu/system/install.scm en el árbol de fuentes, y vea también Invocación de guix system para más información acerca de la imagen de instalación. 3.10 Construcción de la imagen de instalación para placas ARM Muchos dispositivos con procesador ARM necesitan una variante específica del cargador de arranque U-Boot . Si construye una imagen de disco y el cargador de arranque no está disponible de otro modo (en otra unidad de arranque, etc.), es recomendable construir una imagen que incluya el cargador, específicamente: guix system disk-image --system=armhf-linux -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")' A20-OLinuXino-Lime2 es el nombre de la placa. Si especifica una placa no válida, una lista de placas posibles será mostrada. Siguiente: Desarrollo , Anterior: Instalación del sistema , Subir: Top [ Índice general ][ Índice ] 4 Gestión de paquetes El propósito de GNU Guix es permitir a las usuarias instalar, actualizar y borrar fácilmente paquetes de software, sin tener que conocer acerca de sus procedimientos de construcción o dependencias. Guix también va más allá de este conjunto obvio de características. Este capítulo describe las principales características de Guix, así como las herramientas de gestión de paquetes que ofrece. Junto a la interfaz de línea de órdenes descrita a continuación (véase guix package , también puede usar la interfaz Emacs-Guix (véase The Emacs Guix Reference Manual ), tras la instalación del paquete emacs-guix (ejecute la orden M-x guix-help para iniciarse en su uso): guix install emacs-guix • Características : Cómo Guix dará brillo a su vida. • Invocación de guix package : Instalación de paquetes, borrado, etc. • Sustituciones : Descargar binarios pre-construidos. • Paquetes con múltiples salidas : Un único paquete de fuentes, múltiples salidas. • Invocación de guix gc : Ejecutar el recolector de basura. • Invocación de guix pull : Obtener la última versión de Guix y la distribución. • Canales : Personalizar el recolector de basura. • Inferiores : Interactuar con otra revisión de Guix. • Invocación de guix describe : Muestra información acerca de su revisión de Guix. • Invocación de guix archive : Exportar e importar ficheros del almacén. Siguiente: Invocación de guix package , Subir: Gestión de paquetes [ Índice general ][ Índice ] 4.1 Características Cuando se usa Guix, cada paquete se encuentra en el almacén de paquetes , en su propio directorio—algo que se asemeja a /gnu/store/xxx-paquete-1.2 , donde xxx es una cadena en base32. En vez de referirse a estos directorios, las usuarias tienen su propio perfil , el cual apunta a los paquetes que realmente desean usar. Estos perfiles se almacenan en el directorio de cada usuaria, en $HOME/.guix-profile . Por ejemplo, alicia instala GCC 4.7.2. Como resultado, /home/alicia/.guix-profile/bin/gcc apunta a /gnu/store/…-gcc-4.7.2/bin/gcc . Ahora, en la misma máquina, rober ha instalado ya GCC 4.8.0. El perfil de rober simplemente sigue apuntando a /gnu/store/…-gcc-4.8.0/bin/gcc —es decir, ambas versiones de GCC pueden coexistir en el mismo sistema sin ninguna interferencia. La orden guix package es la herramienta central para gestión de paquetes (véase Invocación de guix package ). Opera en los perfiles de usuaria, y puede ser usada con privilegios de usuaria normal . La orden proporciona las operaciones obvias de instalación, borrado y actualización. Cada invocación es en realidad una transacción : o bien la operación especificada se realiza satisfactoriamente, o bien nada sucede. Por tanto, si el proceso guix package es finalizado durante una transacción, o un fallo eléctrico ocurre durante la transacción, el perfil de usuaria permanece en su estado previo, y permanece usable. Además, cualquier transacción de paquetes puede ser vuelta atrás . Si, por ejemplo, una actualización instala una nueva versión de un paquete que resulta tener un error importante, las usuarias pueden volver a la instancia previa de su perfil, de la cual se tiene constancia que funcionaba bien. De igual modo, la configuración global del sistema en Guix está sujeta a actualizaciones transaccionales y vuelta atrás (véase Uso de la configuración del sistema ). Todos los paquetes en el almacén de paquetes pueden ser eliminados por el recolector de basura . Guix puede determinar qué paquetes están siendo todavía referenciados por los perfiles de usuarias, y eliminar aquellos que, de forma demostrable, no están referenciados (véase Invocación de guix gc ). Las usuarias pueden también borrar explícitamente generaciones antiguas de su perfil para que los paquetes referenciados en ellas puedan ser recolectadas. Guix toma una aproximación puramente funcional en la gestión de paquetes, como se describe en la introducción (véase Introducción ). Cada nombre de directorio de paquete en /gnu/store contiene un hash de todas las entradas que fueron usadas para construir el paquete—compilador, bibliotecas, guiones de construcción, etc. Esta correspondencia directa permite a las usuarias asegurarse que una instalación dada de un paquete corresponde al estado actual de su distribución. Esto también ayuda a maximizar la reproducibilidad de la construcción : gracias al uso de entornos aislados de construcción, una construcción dada probablemente generará ficheros idénticos bit-a-bit cuando se realice en máquinas diferentes (véase container ). Estos cimientos permiten a Guix ofrecer despliegues transparentes de binarios/fuentes . Cuando un binario pre-construido para un elemento de /gnu/store está disponible para descarga de una fuente externa—una sustitución , Guix simplemente lo descarga y desempaqueta; en otro caso construye el paquete de las fuentes, localmente (véase Sustituciones ). Debido a que los resultados de construcción son normalmente reproducibles bit-a-bit, las usuarias no tienen que confiar en los servidores que proporcionan sustituciones: pueden forzar una construcción local y retar a las proveedoras (véase Invocación de guix challenge ). El control sobre el entorno de construcción es una característica que también es útil para desarrolladoras. La orden guix environment permite a desarrolladoras de un paquete configurar rápidamente el entorno de desarrollo correcto para su paquete, sin tener que instalar manualmente las dependencias del paquete en su perfil (véase Invocación de guix environment ). Todo Guix y sus definiciones de paquetes están bajo control de versiones, y guix pull le permite “viajar en el tiempo” por la historia del mismo Guix (véase Invocación de guix pull ). Esto hace posible replicar una instancia de Guix en una máquina diferente o en un punto posterior del tiempo, lo que a su vez le permite replicar entornos de software completos , mientras que mantiene un preciso seguimiento de la procedencia del software. Siguiente: Sustituciones , Anterior: Características , Subir: Gestión de paquetes [ Índice general ][ Índice ] 4.2 Invocación de guix package La orden guix package es la herramienta que permite a las usuarias instalar, actualizar y borrar paquetes, así como volver a configuraciones previas. Opera únicamente en el perfil propio de la usuaria, y funciona con privilegios de usuaria normal (véase Características ). Su sintaxis es: guix package opciones Primariamente, opciones especifica las operaciones a ser realizadas durante la transacción. Al completarse, un nuevo perfil es creado, pero las generaciones previas del perfil permanecen disponibles, en caso de que la usuaria quisiera volver atrás. Por ejemplo, para borrar lua e instalar guile y guile-cairo en una única transacción: guix package -r lua -i guile guile-cairo Para su conveniencia, también se proporcionan los siguientes alias: guix search es un alias de guix package -s , guix install es un alias de guix package -i , guix remove es un alias de guix package -r y guix upgrade es un alias de guix package -u . Estos alias tienen menos capacidad expresiva que guix package y proporcionan menos opciones, por lo que en algunos casos es probable que desee usar guix package directamente. guix package también proporciona una aproximación declarativa , donde la usuaria especifica el conjunto exacto de paquetes a poner disponibles y la pasa a través de la opción --manifest (véase --manifest ). Para cada usuaria, un enlace simbólico al perfil predeterminado de la usuaria es creado en $HOME/.guix-profile . Este enlace simbólico siempre apunta a la generación actual del perfil predeterminado de la usuaria. Por lo tanto, las usuarias pueden añadir $HOME/.guix-profile/bin a su variable de entorno PATH , y demás. Si no está usando el sistema Guix, considere la adición de las siguientes líneas en su ~/.bash_profile (véase Bash Startup Files en The GNU Bash Reference Manual ) de manera que los nuevos shell que ejecute obtengan todas las definiciones correctas de las variables de entorno: GUIX_PROFILE="$HOME/.guix-profile" ; \ source "$HOME/.guix-profile/etc/profile" En una configuración multiusuaria, los perfiles de usuaria se almacenan en un lugar registrado como una raíz del sistema de ficheros , a la que apunta $HOME/.guix-profile (véase Invocación de guix gc ). Ese directorio normalmente es localstatedir /guix/profiles/per-user/ usuaria , donde localstatedir es el valor pasado a configure como --localstatedir y usuaria es el nombre de usuaria. El directorio per-user se crea cuando se lanza guix-daemon , y el subdirectorio usuaria es creado por guix package . Las opciones pueden ser las siguientes: --install= paquete … -i paquete … Instala los paquete s especificados. Cada paquete puede especificar un nombre simple de paquete, como por ejemplo guile , o un nombre de paquete seguido por una arroba y el número de versión, como por ejemplo guile@1.8.8 o simplemente guile@1.8 (en el último caso la última versión con 1.8 como prefijo es seleccionada). Si no se especifica un número de versión, la última versión disponible será seleccionada. Además, paquete puede contener dos puntos, seguido por el nombre de una de las salidas del paquete, como en gcc:doc o binutils@2.22:lib (véase Paquetes con múltiples salidas ). Los paquetes con el nombre correspondiente (y opcionalmente la versión) se buscan entre los módulos de la distribución GNU (véase Módulos de paquetes ). A veces los paquetes tienen entradas propagadas : estas son las dependencias que se instalan automáticamente junto al paquete requerido (véase propagated-inputs in package objects , para información sobre las entradas propagadas en las definiciones de paquete). Un ejemplo es la biblioteca GNU MPC: sus ficheros de cabecera C hacen referencia a los de la biblioteca GNU MPFR, que a su vez hacen referencia a los de la biblioteca GMP. Por tanto, cuando se instala MPC, las bibliotecas MPFR y GMP también se instalan en el perfil; borrar MPC también borra MPFR y GMP—a menos que también se hayan instalado explícitamente por la usuaria. Por otra parte, los paquetes a veces dependen de la definición de variables de entorno para sus rutas de búsqueda (véase a continuación la explicación de --seach-paths ). Cualquier definición de variable de entorno que falte o sea posiblemente incorrecta se informa aquí. --install-from-expression= exp -e exp Instala el paquete al que exp evalúa. exp debe ser una expresión Scheme que evalúe a un objeto <package> . Esta opción es notablemente útil para diferenciar entre variantes con el mismo nombre de paquete, con expresiones como (@ (gnu packages base) guile-final) . Fíjese que esta opción instala la primera salida del paquete especificado, lo cual puede ser insuficiente cuando se necesita una salida específica de un paquete con múltiples salidas. --install-from-file= fichero -f fichero Instala el paquete que resulta de evaluar el código en fichero . Como un ejemplo, fichero puede contener una definición como esta (véase Definición de paquetes ): (use-modules (guix) (guix build-system gnu) (guix licenses)) (package (name "hello") (version "2.10") (source (origin (method url-fetch) (uri (string-append "mirror://gnu/hello/hello-" version ".tar.gz")) (sha256 (base32 "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i")))) (build-system gnu-build-system) (synopsis "Hello, GNU world: An example GNU package") (description "Guess what GNU Hello prints!") (home-page "http://www.gnu.org/software/hello/") (license gpl3+)) Las desarrolladoras pueden encontrarlo útil para incluir un fichero guix.scm in la raíz del árbol de fuentes de su proyecto que puede ser usado para probar imágenes de desarrollo y crear entornos de desarrollo reproducibles (véase Invocación de guix environment ). --remove= paquete … -r paquete … Borra los paquete s especificados. Como en --install , cada paquete puede especificar un número de versión y/o un nombre de salida además del nombre del paquete. Por ejemplo, -r glibc:debug eliminaría la salida debug de glibc . --upgrade[= regexp …] -u [ regexp …] Actualiza todos los paquetes instalados. Si se especifica una o más expresiones regular regexp , actualiza únicamente los paquetes instalados cuyo nombre es aceptado por regexp . Véase también la opción --do-not-upgrade más adelante. Tenga en cuenta que esto actualiza los paquetes a la última versión encontrada en la distribución instalada actualmente. Para actualizar su distribución, debe ejecutar regularmente guix pull (véase Invocación de guix pull ). --do-not-upgrade[= regexp …] Cuando se usa junto a la opción --upgrade , no actualiza ningún paquete cuyo nombre sea aceptado por regexp . Por ejemplo, para actualizar todos los paquetes en el perfil actual excepto aquellos que contengan la cadena “emacs”: $ guix package --upgrade . --do-not-upgrade emacs --manifest= fichero -m fichero Crea una nueva generación del perfil desde el objeto de manifiesto devuelto por el código Scheme en fichero . Esto le permite declarar los contenidos del perfil en vez de construirlo a través de una secuencia de --install y órdenes similares. La ventaja es que fichero puede ponerse bajo control de versiones, copiarse a máquinas diferentes para reproducir el mismo perfil, y demás. fichero debe devolver un objeto manifest , que es básicamente una lista de paquetes: (use-package-modules guile emacs) (packages->manifest (list emacs guile-2.0 ;; Usa una salida específica del paquete. (list guile-2.0 "debug"))) En este ejemplo tenemos que conocer qué módulos definen las variables emacs y guile-2.0 para proporcionar la línea use-package-modules correcta, lo cual puede ser complicado. En cambio podemos proporcionar especificaciones regulares de paquetes y dejar a specifications->manifest buscar los objetos de paquete correspondientes así: (specifications->manifest '("emacs" "guile@2.2" "guile@2.2:debug")) --roll-back Vuelve a la generación previa del perfil—es decir, deshace la última transacción. Cuando se combina con opciones como --install , la vuelta atrás ocurre antes que cualquier acción. Cuando se vuelve atrás en la primera generación que realmente contiene paquetes instalados, se hace que el perfil apunte a la generación cero , la cual no contiene ningún fichero a excepción de sus propios metadatos. Después de haber vuelto atrás, instalar, borrar o actualizar paquetes sobreescribe las generaciones futuras previas. Por tanto, la historia de las generaciones en un perfil es siempre linear. --switch-generation= patrón -S patrón Cambia a una generación particular definida por el patrón . patrón puede ser tanto un número de generación como un número prefijado con “+” o “-”. Esto último significa: mueve atrás/hacia delante el número especificado de generaciones. Por ejemplo, si quiere volver a la última generación antes de --roll-back , use --switch-generation=+1 . La diferencia entre --roll-back y --switch-generation=-1 es que --switch-generation no creará una generación cero, así que si la generación especificada no existe, la generación actual no se verá cambiada. --search-paths[= tipo ] Informa de variables de entorno, en sintaxis Bash, que pueden necesitarse para usar el conjunto de paquetes instalado. Estas variables de entorno se usan para especificar las rutas de búsqueda para ficheros usadas por algunos de los paquetes. Por ejemplo, GCC necesita que las variables de entorno CPATH y LIBRARY_PATH estén definidas para poder buscar cabeceras y bibliotecas en el perfil de la usuaria (véase Environment Variables en Using the GNU Compiler Collection (GCC) ). Si GCC y, digamos, la biblioteca de C están instaladas en el perfil, entonces --search-paths sugerirá fijar dichas variables a perfil /include y perfil /lib respectivamente. El caso de uso típico es para definir estas variables de entorno en el shell: $ eval `guix package --search-paths` tipo puede ser exact , prefix o suffix , lo que significa que las definiciones de variables de entorno devueltas serán respectivamente las configuraciones exactas, prefijos o sufijos del valor actual de dichas variables. Cuando se omite, el valor predeterminado de tipo es exact . Esta opción puede usarse para calcular las rutas de búsqueda combinadas de varios perfiles. Considere este ejemplo: $ guix package -p foo -i guile $ guix package -p bar -i guile-json $ guix package -p foo -p bar --search-paths La última orden informa sobre la variable GUILE_LOAD_PATH , aunque, tomada individualmente, ni foo ni bar hubieran llevado a esa recomendación. --profile= perfil -p perfil Usa perfil en vez del perfil predeterminado de la usuaria. --allow-collisions Permite colisiones de paquetes en el nuevo perfil. ¡Úselo bajo su propio riesgo! Por defecto, guix package informa como un error las colisiones en el perfil. Las colisiones ocurren cuando dos o más versiones diferentes o variantes de un paquete dado se han seleccionado para el perfil. --bootstrap Use el Guile usado para el lanzamiento para construir el perfil. Esta opción es util únicamente a las desarrolladoras de la distribución. Además de estas acciones, guix package acepta las siguientes opciones para consultar el estado actual de un perfil, o la disponibilidad de paquetes: --search= regexp -s regexp Enumera los paquetes disponibles cuyo nombre, sinopsis o descripción corresponde con regexp (sin tener en cuenta la capitalización), ordenados por relevancia. Imprime todos los metadatos de los paquetes coincidentes en formato recutils (véase GNU recutils databases en GNU recutils manual ). Esto permite extraer campos específicos usando la orden recsel , por ejemplo: $ guix package -s malloc | recsel -p name,version,relevance name: jemalloc version: 4.5.0 relevance: 6 name: glibc version: 2.25 relevance: 1 name: libgc version: 7.6.0 relevance: 1 De manera similar, para mostrar el nombre de todos los paquetes disponibles bajo los términos de la GNU LGPL versión 3: $ guix package -s "" | recsel -p name -e 'license ~ "LGPL 3"' name: elfutils name: gmp … También es posible refinar los resultados de búsqueda mediante el uso de varias opciones -s , o varios parámetros a guix search . Por ejemplo, la siguiente orden devuelve un lista de juegos de mesa 10 (esta vez mediante el uso del alias guix search : $ guix search '\<board\>' game | recsel -p name name: gnubg … Si omitimos -s game , también obtendríamos paquetes de software que tengan que ver con placas de circuitos impresos ("circuit board" en inglés); borrar los signos mayor y menor alrededor de board añadiría paquetes que tienen que ver con teclados (keyboard en inglés). Y ahora para un ejemplo más elaborado. La siguiente orden busca bibliotecas criptográficas, descarta bibliotecas Haskell, Perl, Python y Ruby, e imprime el nombre y la sinopsis de los paquetes resultantes: $ guix search crypto library | \ recsel -e '! (name ~ "^(ghc|perl|python|ruby)")' -p name,synopsis Véase Selection Expressions en GNU recutils manual , para más información en expresiones de selección para recsel -e . --show= paquete Muestra los detalles del paquete , tomado de la lista disponible de paquetes, en formato recutils (véase GNU recutils databases en GNU recutils manual ). $ guix package --show=python | recsel -p name,version name: python version: 2.7.6 name: python version: 3.3.5 También puede especificar el nombre completo de un paquete para únicamente obtener detalles sobre una versión específica: $ guix package --show=python@3.4 | recsel -p name,version name: python version: 3.4.3 --list-installed[= regexp ] -I [ regexp ] Enumera los paquetes actualmente instalados en el perfil especificado, con los últimos paquetes instalados mostrados al final. Cuando se especifica regexp , enumera únicamente los paquetes instalados cuyos nombres son aceptados por regexp . Por cada paquete instalado, imprime los siguientes elementos, separados por tabuladores: el nombre del paquete, la cadena de versión, la parte del paquete que está instalada (por ejemplo, out para la salida predeterminada, include para sus cabeceras, etc.), y la ruta de este paquete en el almacén. --list-available[= regexp ] -A [ regexp ] Enumera los paquetes disponibles actualmente en la distribución para este sistema (véase Distribución GNU ). Cuando se especifica regexp , enumera únicamente paquetes instalados cuyo nombre coincide con regexp . Por cada paquete, imprime los siguientes elementos separados por tabuladores: su nombre, su cadena de versión, las partes del paquete (véase Paquetes con múltiples salidas ) y la dirección de las fuentes de su definición. --list-generations[= patrón ] -l [ patrón ] Devuelve una lista de generaciones junto a sus fechas de creación; para cada generación, muestra los paquetes instalados, con los paquetes instalados más recientemente mostrados los últimos. Fíjese que la generación cero nunca se muestra. Por cada paquete instalado, imprime los siguientes elementos, separados por tabuladores: el nombre de un paquete, su cadena de versión, la parte del paquete que está instalada (véase Paquetes con múltiples salidas ), y la ruta de este paquete en el almacén. Cuando se usa patrón , la orden devuelve únicamente las generaciones que se ajustan al patrón. Entre los patrones adecuados se encuentran: Enteros y enteros separados por comas . Ambos patrones denotan números de generación. Por ejemplo, --list-generations=1 devuelve la primera. Y --list-generations=1,8,2 devuelve las tres generaciones en el orden especificado. No se permiten ni espacios ni una coma al final. Rangos . --list-generations=2..9 imprime las generaciones especificadas y todas las intermedias. Fíjese que el inicio de un rango debe ser menor a su fin. También es posible omitir el destino final. Por ejemplo, --list-generations=2.. devuelve todas las generaciones empezando por la segunda. Duraciones . Puede también obtener los últimos N días, semanas, o meses pasando un entero junto a la primera letra de la duración. Por ejemplo, --list-generations=20d enumera las generaciones que tienen hasta 20 días de antigüedad. --delete-generations[= patrón ] -d [ patrón ] Cuando se omite patrón , borra todas las generaciones excepto la actual. Esta orden acepta los mismos patrones que --list-generations . Cuando se especifica un patrón , borra las generaciones coincidentes. Cuando el patrón especifica una duración, las generaciones más antiguas que la duración especificada son las borradas. Por ejemplo, --delete-generations=1m borra las generaciones de más de un mes de antigüedad. Si la generación actual entra en el patrón, no es borrada. Tampoco la generación cero es borrada nunca. Fíjese que borrar generaciones previene volver atrás a ellas. Consecuentemente esta orden debe ser usada con cuidado. Finalmente, ya que guix package puede lanzar procesos de construcción en realidad, acepta todas las opciones comunes de construcción (véase Opciones comunes de construcción ). También acepta opciones de transformación de paquetes, como --with-source (véase Opciones de transformación de paquetes ). No obstante, fíjese que las transformaciones del paquete se pierden al actualizar; para preservar las transformaciones entre actualizaciones, debe definir su propia variante del paquete en un módulo Guile y añadirlo a GUIX_PACKAGE_PATH (véase Definición de paquetes ). Siguiente: Paquetes con múltiples salidas , Anterior: Invocación de guix package , Subir: Gestión de paquetes [ Índice general ][ Índice ] 4.3 Sustituciones Guix permite despliegues transparentes de fuentes/binarios, lo que significa que puede tanto construir cosas localmente, como descargar elementos preconstruidos de un servidor, o ambas. Llamamos a esos elementos preconstruidos sustituciones —son sustituciones de los resultados de construcciones locales. En muchos casos, descargar una sustitución es mucho más rápido que construirla localmente. Las sustituciones pueden ser cualquier cosa que resulte de una construcción de una derivación (véase Derivaciones ). Por supuesto, en el caso común, son paquetes binarios preconstruidos, pero los archivos de fuentes, por ejemplo, que también resultan de construcciones de derivaciones, pueden estar disponibles como sustituciones. • Servidor oficial de sustituciones. : Una fuente particular de sustituciones. • Autorización de servidores de sustituciones : Cómo activar o desactivar las sustituciones. • Verificación de sustituciones : Cómo verifica las sustituciones Guix. • Configuración de la pasarela. : Cómo obtener sustituciones a través de una pasarela. • Fallos en las sustituciones : Qué pasa cuando una sustitución falla. • Sobre la confianza en binarios : ¿Cómo puede usted confiar en esa masa informe de datos binarios? Siguiente: Autorización de servidores de sustituciones , Subir: Sustituciones [ Índice general ][ Índice ] 4.3.1 Servidor oficial de sustituciones. El servidor ci.guix.gnu.org es una fachada a una granja de construcción oficial que construye paquetes de Guix continuamente para algunas arquitecturas, y los pone disponibles como sustituciones. Esta es la fuente predeterminada de sustituciones; puede ser forzada a cambiar pasando la opción --substitute-urls bien a guix-daemon (véase guix-daemon --substitute-urls ) o bien a herramientas cliente como guix package (véase client --substitute-urls option ). Las URLs de sustituciones pueden ser tanto HTTP como HTTPS. Se recomienda HTTPS porque las comunicaciones están cifradas; de modo contrario, usar HTTP hace visibles todas las comunicaciones para alguien que las intercepte, quien puede usar la información obtenida para determinar, por ejemplo, si su sistema tiene vulnerabilidades de seguridad sin parchear. El uso de sustituciones de la granja de construcción oficial se realiza de manera predeterminada cuando se usa el sistema Guix (véase Distribución GNU ). No obstante, no se realiza de manera predeterminada cuando se usa Guix en una distribución anfitriona, a menos que las active explícitamente via uno de los pasos recomendados de instalación (véase Instalación ). Los siguientes párrafos describen como activar o desactivar las sustituciones para la granja oficial de construcción; el mismo procedimiento puede usarse para activar las sustituciones desde cualquier otro servidor que las proporcione. Siguiente: Verificación de sustituciones , Anterior: Servidor oficial de sustituciones. , Subir: Sustituciones [ Índice general ][ Índice ] 4.3.2 Autorización de servidores de sustituciones Para permitir a Guix descargar sustituciones de ci.guix.gnu.org o un espejo suyo, debe añadir su clave pública a la lista de control de acceso (ACL) de las importaciones de archivos, mediante el uso de la orden guix archive (véase Invocación de guix archive ). Hacerlo implica que confía que ci.guix.gnu.org no ha sido comprometido y proporciona sustituciones genuinas. La clave pública para ci.guix.gnu.org se instala junto a Guix, en prefijo /share/guix/ci.guix.gnu.org.pub , donde prefijo es el prefij de instalación de Guix. Si ha instalado Guix desde las fuentes, debe asegurarse de que comprobó la firma GPG de guix-1.0.1.tar.gz , el cual contiene el fichero de clave pública. Una vez hecho, puede ejecutar algo así: # guix archive --authorize < prefijo /share/guix/ci.guix.gnu.org.pub Nota: De manera similar, el fichero hydra.gnu.org.pub contiene la clave pública para una granja de construcción independiente que también es parte del proyecto, la cual se puede encontrar en ‘ https://mirror.hydra.gnu.org '. Una vez esté autorizada, la salida de una orden como guix build debería cambiar de algo como: $ guix build emacs --dry-run The following derivations would be built: /gnu/store/yr7bnx8xwcayd6j95r2clmkdl1qh688w-emacs-24.3.drv /gnu/store/x8qsh1hlhgjx6cwsjyvybnfv2i37z23w-dbus-1.6.4.tar.gz.drv /gnu/store/1ixwp12fl950d15h2cj11c73733jay0z-alsa-lib-1.0.27.1.tar.bz2.drv /gnu/store/nlma1pw0p603fpfiqy7kn4zm105r5dmw-util-linux-2.21.drv … a algo así: $ guix build emacs --dry-run 112.3 MB would be downloaded: /gnu/store/pk3n22lbq6ydamyymqkkz7i69wiwjiwi-emacs-24.3 /gnu/store/2ygn4ncnhrpr61rssa6z0d9x22si0va3-libjpeg-8d /gnu/store/71yz6lgx4dazma9dwn2mcjxaah9w77jq-cairo-1.12.16 /gnu/store/7zdhgp0n1518lvfn8mb96sxqfmvqrl7v-libxrender-0.9.7 … Esto indica que las sustituciones de ci.guix.gnu.org son usables y serán descargadas, cuando sea posible, para construcciones futuras. El mecanismo de sustituciones puede ser desactivado globalmente ejecutando guix-daemon con --no-subsitutes (véase Invocación de guix-daemon ). También puede ser desactivado temporalmente pasando la opción --no-substitutes a guix package , guix build y otras herramientas de línea de órdenes. Siguiente: Configuración de la pasarela. , Anterior: Autorización de servidores de sustituciones , Subir: Sustituciones [ Índice general ][ Índice ] 4.3.3 Verificación de sustituciones Guix detecta y emite errores cuando se intenta usar una sustitución que ha sido adulterado. Del mismo modo, ignora las sustituciones que no están firmadas, o que no están firmadas por una de las firmas enumeradas en la ACL. No obstante hay una excepción: si un servidor no autorizado proporciona sustituciones que son idénticas bit-a-bit a aquellas proporcionadas por un servidor autorizado, entonces el servidor no autorizado puede ser usado para descargas. Por ejemplo, asumiendo que hemos seleccionado dos servidores de sustituciones con esta opción: --substitute-urls="https://a.example.org https://b.example.org" Si la ACL contiene únicamente la clave para b.example.org , y si a.example.org resulta que proporciona exactamente las mismas sustituciones, Guix descargará sustituciones de a.example.org porque viene primero en la lista y puede ser considerado un espejo de b.example.org . En la práctica, máquinas de construcción independientes producen habitualmente los mismos binarios, gracias a las construcciones reproducibles bit-a-bit (véase a continuación). Cuando se usa HTTPS, el certificado X.509 del servidor no se valida (en otras palabras, el servidor no está verificado), lo contrario del comportamiento habitual de los navegadores Web. Esto es debido a que Guix verifica la información misma de las sustituciones, como se ha explicado anteriormente, lo cual nos concierne (mientras que los certificados X.509 tratan de verificar las conexiones entre nombres de dominio y claves públicas). Siguiente: Fallos en las sustituciones , Anterior: Verificación de sustituciones , Subir: Sustituciones [ Índice general ][ Índice ] 4.3.4 Configuración de la pasarela. Las sustituciones se descargan por HTTP o HTTPS. La variable de entorno http_proxy puede ser incluida en el entorno de guix-daemon y la respeta para las descargas de sustituciones. Fíjese que el valor de http_proxy en el entorno en que guix build , guix package y otras aplicaciones cliente se ejecuten no tiene ningún efecto . Siguiente: Sobre la confianza en binarios , Anterior: Configuración de la pasarela. , Subir: Sustituciones [ Índice general ][ Índice ] 4.3.5 Fallos en las sustituciones Incluso cuando una sustitución de una derivación está disponible, a veces el intento de sustitución puede fallar. Esto puede suceder por varias razones: el servidor de sustituciones puede estar desconectado, la sustitución puede haber sido borrada, la conexión puede interrumpirse, etc. Cuando las sustituciones están activadas y una sustitución para una derivación está disponible, pero el intento de sustitución falla, Guix intentará construir la derivación localmente dependiendo si se proporcionó la opción --fallback (véase common build option --fallback ). Específicamente, si no se pasó --fallback , no se realizarán construcciones locales, y la derivación se considera se considera fallida. No obstante, si se pasó --fallback , Guix intentará construir la derivación localmente, y el éxito o fracaso de la derivación depende del éxito o fracaso de la construcción local. Fíjese que cuando las sustituciones están desactivadas o no hay sustituciones disponibles para la derivación en cuestión, la construcción local se realizará siempre , independientemente de si se pasó la opción --fallback . Para hacerse una idea de cuantas sustituciones hay disponibles en este momento, puede intentar ejecutar la orden guix weather (véase Invocación de guix weather ). Esta orden proporciona estadísticas de las sustituciones proporcionadas por un servidor. Anterior: Fallos en las sustituciones , Subir: Sustituciones [ Índice general ][ Índice ] 4.3.6 Sobre la confianza en binarios Hoy en día, el control individual sobre nuestra propia computación está a merced de instituciones, empresas y grupos con suficiente poder y determinación para subvertir la infraestructura de computación y explotar sus vulnerabilidades. Mientras que usar las sustituciones de ci.guix.gnu.org puede ser conveniente, recomendamos a las usuarias también construir sus paquetes, o incluso mantener su propia granja de construcción, de modo que ci.guix.gnu.org sea un objetivo menos interesante. Una manera de ayudar es publicando el software que construya usando guix publish de modo que otras tengan otro servidor más como opción para descargar sustituciones (véase Invocación de guix publish ). Guix tiene los cimientos para maximizar la reproducibilidad de las construcciones (véase Características ). En la mayor parte de los casos, construcciones independientes de un paquete o derivación dada deben emitir resultados idénticos bit a bit. Por tanto, a través de un conjunto diverso de construcciones independientes de paquetes, podemos reforzar la integridad de nuestros sistemas. La orden guix challenge intenta ayudar a las usuarias en comprobar servidores de sustituciones, y asiste a las desarrolladoras encontrando construcciones no deterministas de paquetes (véase Invocación de guix challenge ). Similarmente, la opción --check de guix build permite a las usuarias si las sustituciones previamente instaladas son genuinas reconstruyendolas localmente (véase guix build --check ). En el futuro, queremos que Guix permita la publicación y obtención de binarios hacia/desde otras usuarias, entre pares (P2P). En caso de interesarle hablar sobre este proyecto, unase a nosotras en guix-devel@gnu.org . Siguiente: Invocación de guix gc , Anterior: Sustituciones , Subir: Gestión de paquetes [ Índice general ][ Índice ] 4.4 Paquetes con múltiples salidas Habitualmente, los paquetes definidos en Guix tienen una salida única—es decir, el paquete de fuentes proporcionará exactamente un directorio en el almacén. Cuando se ejecuta guix install glibc , se instala la salida predeterminada del paquete GNU libc; la salida predeterminada se llama out , pero su nombre puede omitirse como se mostró en esta orden. En este caso particular, la salida predeterminada de glibc contiene todos ficheros de cabecera C, bibliotecas dinámicas, bibliotecas estáticas, documentación Info y otros ficheros auxiliares. A veces es más apropiado separar varios tipos de ficheros producidos por un paquete único de fuentes en salidas separadas. Por ejemplo, la biblioteca C GLib (usada por GTK+ y paquetes relacionados) instala más de 20 MiB de documentación de referencia como páginas HTML. Para ahorrar espacio para usuarias que no la necesiten, la documentación va a una salida separada, llamada doc . Para instalar la salida principal de GLib, que contiene todo menos la documentación, se debe ejecutar: guix install glib La orden que instala su documentación es: guix install glib:doc Algunos paquetes instalan programas con diferentes “huellas de dependencias”. Por ejemplo, el paquete WordNet instala tanto herramientas de línea de órdenes como interfaces gráficas de usuaria (IGU). Las primeras dependen únicamente de la biblioteca de C, mientras que las últimas dependen en Tcl/Tk y las bibliotecas de X subyacentes. En este caso, dejamos las herramientas de línea de órdenes en la salida predeterminada, mientras que las IGU están en una salida separada. Esto permite a las usuarias que no necesitan una IGU ahorrar espacio. La orden guix size puede ayudar a exponer estas situaciones (véase Invocación de guix size ). guix graph también puede ser útil (véase Invocación de guix graph ). Hay varios de estos paquetes con salida múltiple en la distribución GNU. Otros nombres de salida convencionales incluyen lib para bibliotecas y posiblemente ficheros de cabecera, bin para programas independientes y debug para información de depuración (véase Instalación de ficheros de depuración ). La salida de los paquetes se enumera en la tercera columna del resultado de guix package --list-available (véase Invocación de guix package ). Siguiente: Invocación de guix pull , Anterior: Paquetes con múltiples salidas , Subir: Gestión de paquetes [ Índice general ][ Índice ] 4.5 Invocación de guix gc Los paquetes instalados, pero no usados, pueden ser recolectados . La orden guix gc permite a las
...
-
http://www.gnu.org/savannah-checkouts/gnu/guix/manual/es/guix.es.html
- [detail]
- [similar]
PREV
NEXT