Commit | Line | Data |
---|---|---|
3b919e01 LC |
1 | @node Contribuir |
2 | @chapter Contribuir | |
3 | ||
4 | Este proyecto es un esfuerzo colaborativo, y ¡necesitamos su ayuda para que | |
5 | crezca! Por favor, contacte con nosotras en @email{guix-devel@@gnu.org} y en | |
6 | @code{#guix} en la red IRC Freenode. Estamos abiertas a ideas, informes de | |
7 | errores, parches y cualquier cosa que pueda ser de ayuda para el | |
8 | proyecto. Especialmente se agradece ayuda en empaquetamiento | |
9 | (@pxref{Guías de empaquetamiento}). | |
10 | ||
11 | @cindex código de conducta, de contribuidoras | |
12 | @cindex acuerdo de contribución | |
13 | Queremos proporcionar un entorno cálido, amistoso y libre de acoso, para que | |
14 | cualquiera pueda contribuir al máximo de sus capacidades. Para este fin | |
15 | nuestro proyecto usa un ``Acuerdo de Contribución'', que fue adaptado de | |
16 | @url{http://contributor-coventant.org}. Se puede encontrar una versión local | |
17 | en el fichero @file{CODE-OF-CONDUCT} del árbol de fuentes. | |
18 | ||
19 | Las contribuidoras no están obligadas a usar su nombre legal en los parches | |
20 | ni en la comunicación on-line; pueden usar cualquier nombre o seudónimo de | |
21 | su elección. | |
22 | ||
23 | @menu | |
24 | * Construcción desde Git:: Lo último y mejor. | |
25 | * Ejecución de Guix antes de estar instalado:: Trucos de hacker. | |
26 | * La configuración perfecta:: Las herramientas adecuadas. | |
27 | * Guías de empaquetamiento:: Crecimiento de la distribución. | |
28 | * Estilo de codificación:: Higiene de la contribuidora. | |
29 | * Envío de parches:: Comparta su trabajo. | |
30 | @end menu | |
31 | ||
32 | @node Construcción desde Git | |
33 | @section Construcción desde Git | |
34 | ||
35 | Si quiere picar en el mismo Guix se recomienda usar la última versión del | |
36 | repositorio Git: | |
37 | ||
38 | @example | |
39 | git clone https://git.savannah.gnu.org/git/guix.git | |
40 | @end example | |
41 | ||
42 | Cuando se compila Guix de una copia de trabajo local (checkout), se | |
43 | requieren los siguientes paquetes, además de los mencionados en las | |
44 | instrucciones de instalación (@pxref{Requisitos}). | |
45 | ||
46 | @itemize | |
47 | @item @url{http://gnu.org/software/autoconf/, GNU Autoconf}; | |
48 | @item @url{http://gnu.org/software/automake/, GNU Automake}; | |
49 | @item @url{http://gnu.org/software/gettext/, GNU Gettext}; | |
50 | @item @url{http://gnu.org/software/texinfo/, GNU Texinfo}; | |
51 | @item @url{http://www.graphviz.org/, Graphviz}; | |
52 | @item @url{http://www.gnu.org/software/help2man/, GNU Help2man (opcional)}. | |
53 | @end itemize | |
54 | ||
55 | El modo más fácil de preparar un entorno de desarrollo para Guix es, por | |
56 | supuesto, ¡usando Guix! Las siguientes órdenes inician un nuevo intérprete | |
57 | donde todas las dependencias y las variables de entorno apropiadas están | |
58 | listas para picar código en Guix: | |
59 | ||
60 | @example | |
61 | guix environment guix | |
62 | @end example | |
63 | ||
64 | @xref{Invocación de guix environment}, para más información sobre esa orden. Se | |
65 | pueden añadir dependencias adicionales con la opción @option{--ad-hoc}: | |
66 | ||
67 | @example | |
68 | guix environment guix --ad-hoc help2man git strace | |
69 | @end example | |
70 | ||
71 | Ejecute @command{./bootstrap} para generar la infraestructura del sistema de | |
72 | construcción usando Autoconf y Automake. Si obtiene un error como este: | |
73 | ||
74 | @example | |
75 | configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES | |
76 | @end example | |
77 | ||
78 | @noindent | |
79 | probablemente significa que Autoconf no pudo encontrar el fichero pkg.m4, | |
80 | que proporciona pkg-config. Asegurese de que @file{pkg.m4} está | |
81 | disponible. Lo mismo aplica para el conjunto de macros @file{guile.m4} que | |
82 | proporciona Guile. Por ejemplo, si ha instalado Automake en | |
83 | @file{/usr/local}, no va a buscar ficheros @file{.m4} en | |
84 | @file{/usr/share}. En ese caso tiene que ejecutar la siguiente orden: | |
85 | ||
86 | @example | |
87 | export ACLOCAL_PATH=/usr/share/aclocal | |
88 | @end example | |
89 | ||
90 | @xref{Macro Search Path,,, automake, The GNU Automake Manual} para más | |
91 | información. | |
92 | ||
93 | Entonces, ejecute @command{./configure} como siempre. Asegurese de pasar | |
94 | @code{--localstatedir=@var{directorio}}, donde @var{directorio} es el valor | |
95 | de @code{localstatedir} usado por su instalación actual (@pxref{El almacén}, | |
96 | para información sobre esto). | |
97 | ||
98 | Finalmente, tiene que ejecutar @code{make check} para iniciar las pruebas | |
99 | (@pxref{Ejecución de la batería de pruebas}). Si algo falla, eche un vistazo a las | |
100 | instrucciones de instalación (@pxref{Instalación}) o envíe un mensaje---en | |
101 | Inglés---a la @email{guix-devel@@gnu.org, lista de correo}. | |
102 | ||
103 | ||
104 | @node Ejecución de Guix antes de estar instalado | |
105 | @section Ejecución de Guix antes de estar instalado | |
106 | ||
107 | Para mantener un entorno de trabajo estable, encontrará útil probar los | |
108 | cambios hechos en su copia de trabajo local sin instalarlos realmente. De | |
109 | esa manera, puede distinguir entre su sombrero de ``usuaria final'' y el | |
110 | traje de ``harapos''. | |
111 | ||
112 | Para dicho fin, todas las herramientas de línea de órdenes pueden ser usadas | |
113 | incluso si no ha ejecutado @code{make install}. Para hacerlo, primero | |
114 | necesita tener un entorno con todas las dependencias disponibles | |
115 | (@pxref{Construcción desde Git}), y entonces añada al inicio de cada orden | |
116 | @command{./pre-inst-env} (el guión @file{pre-inst-env} se encuentra en la | |
117 | raíz del árbol de compilación de Guix, como en@footnote{La opción | |
118 | @option{-E} a @command{sudo} asegura que @code{GUILE_LOAD_PATH} contiene la | |
119 | información correcta para que @command{guix-daemon} y las herramientas que | |
120 | usa puedan encontrar los módulos Guile que necesitan.}: | |
121 | ||
122 | @example | |
123 | $ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild | |
124 | $ ./pre-inst-env guix build hello | |
125 | @end example | |
126 | ||
127 | @noindent | |
128 | De manera similar, para una sesión de Guile que use los módulos Guix: | |
129 | ||
130 | @example | |
131 | $ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))' | |
132 | ||
133 | ;;; ("x86_64-linux") | |
134 | @end example | |
135 | ||
136 | @noindent | |
137 | @cindex REPL | |
138 | @cindex entorno interactivo | |
139 | @dots{} y para un entorno interactivo (REPL) (@pxref{Using Guile | |
140 | Interactively,,, guile, Guile Reference Manual}): | |
141 | ||
142 | @example | |
143 | $ ./pre-inst-env guile | |
144 | scheme@@(guile-user)> ,use(guix) | |
145 | scheme@@(guile-user)> ,use(gnu) | |
146 | scheme@@(guile-user)> (define serpientes | |
147 | (fold-packages | |
148 | (lambda (paquete lst) | |
149 | (if (string-prefix? "python" | |
150 | (package-name paquete)) | |
151 | (cons paquete lst) | |
152 | lst)) | |
153 | '())) | |
154 | scheme@@(guile-user)> (length serpientes) | |
155 | $1 = 361 | |
156 | @end example | |
157 | ||
158 | El guión @command{pre-inst-env} fija todas las variables de entorno | |
159 | necesarias para permitir esto, incluyendo @env{PATH} y | |
160 | @env{GUILE_LOAD_PATH}. | |
161 | ||
162 | Fíjese que la orden @command{./pre-inst-env guix pull} @emph{no} actualiza | |
163 | el árbol de fuentes local; simplemente actualiza el enlace | |
164 | @file{~/.config/guix/latest} (@pxref{Invocación de guix pull}). Ejecute | |
165 | @command{git pull} si quiere actualizar su árbol de fuentes local. | |
166 | ||
167 | ||
168 | @node La configuración perfecta | |
169 | @section La configuración perfecta | |
170 | ||
171 | La configuración perfecta para hackear en Guix es básicamente la | |
172 | configuración perfecta para hacerlo en Guile (@pxref{Using Guile in Emacs,,, | |
173 | guile, Guile Reference Manual}). Primero, necesita más que un editor, | |
174 | necesita @url{http://www.gnu.org/software/emacs, Emacs}, empoderado por el | |
175 | maravilloso @url{http://nongnu.org/geiser, Geiser}. Para configurarlo, | |
176 | ejecute: | |
177 | ||
178 | @example | |
179 | guix package -i emacs guile emacs-geiser | |
180 | @end example | |
181 | ||
182 | Geiser permite desarrollo incremental e interactivo dentro de Emacs: | |
183 | compilación y evaluación de código dentro de los buffers, acceso a | |
184 | documentación en línea (docstrings), completado dependiente del contexto, | |
185 | @kbd{M-.} para saltar a la definición de un objeto, una consola interactiva | |
186 | (REPL) para probar su código, y más (@pxref{Introducción,,, geiser, Geiser | |
187 | User Manual}). Para desarrollar Guix adecuadamente, asegúrese de aumentar la | |
188 | ruta de carga de Guile (load-path) para que encuentre los ficheros fuente de | |
189 | su copia de trabajo: | |
190 | ||
191 | @lisp | |
192 | ;; @r{Suponiendo que la copia de trabajo de Guix está en ~/src/guix.} | |
193 | (with-eval-after-load 'geiser-guile | |
194 | (add-to-list 'geiser-guile-load-path "~/src/guix")) | |
195 | @end lisp | |
196 | ||
197 | Para realmente editar el código, Emacs tiene un modo limpio para | |
198 | Scheme. Pero además de eso, no debe perderse | |
199 | @url{http://www.emacswiki.org/emacs/ParEdit, Paredit}. Provee de facilidades | |
200 | para operar directamente en el árbol sintáctico como elevar una expresión S | |
201 | o recubrirla, embeber o expulsar la siguiente expresión S, etc. | |
202 | ||
203 | @cindex fragmentos de código | |
204 | @cindex plantillas | |
205 | @cindex reducir la verborrea | |
206 | También proporcionamos plantillas para los mensajes de revisión de git | |
207 | comunes y definiciones de paquetes en el directorio | |
208 | @file{etc/snippets}. Estas plantillas pueden ser usadas con | |
209 | @url{http://joaotavora.github.io/yasnippet, YASnippet} para expandir | |
210 | mnemotécnicos a fragmentos interactivos de texto. Puedes querer añadir el | |
211 | directorio de fragmentos a la variable @var{yas-snippet-dirs} en Emacs. | |
212 | ||
213 | @lisp | |
214 | ;; @r{Suponiendo que la copia de trabajo de Guix está en ~/src/guix.} | |
215 | (with-eval-after-load 'yasnippet | |
216 | (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets")) | |
217 | @end lisp | |
218 | ||
219 | Los fragmentos de mensajes de la revisión dependen de | |
220 | @url{https://magit.vc/, Magit} para mostrar los ficheros preparados. En la | |
221 | edición del mensaje de la revisión teclee @code{add} seguido de @kbd{TAB} | |
222 | (el tabulador) para insertar la plantilla del mensaje de la revisión de | |
223 | adición de un paquete; teclee @code{update} seguido de @kbd{TAB} para | |
224 | insertar una plantilla de actualización de un paquete; teclee @code{https} | |
225 | seguido de @kbd{TAB} para insertar una plantilla para cambiar la URI de la | |
226 | página de un paquete a HTTPS. | |
227 | ||
228 | El fragmento principal para @code{scheme-mode} es activado al teclear | |
229 | @code{package...} seguido de @kbd{TAB}. Este fragmento también inserta el | |
230 | lanzador @code{origin...} que puede ser expandido de nuevo. El fragmento | |
231 | @code{origin} puede a su vez insertar otros identificadores de lanzado | |
232 | terminando en @code{...}, que pueden ser expandidos de nuevo. | |
233 | ||
234 | ||
235 | @node Guías de empaquetamiento | |
236 | @section Guías de empaquetamiento | |
237 | ||
238 | @cindex paquetes, creación | |
239 | La distribución GNU es reciente y puede no disponer de alguno de sus | |
240 | paquetes favoritos. Esta sección describe cómo puede ayudar a hacer crecer | |
241 | la distribución. | |
242 | ||
243 | Los paquetes de software libre habitualmente se distribuyen en forma de | |
244 | @dfn{archivadores de código fuente}---típicamente ficheros @file{tar.gz} que | |
245 | contienen todos los ficheros fuente. Añadir un paquete a la distribución | |
246 | significa esencialmente dos cosas: añadir una @dfn{receta} que describe cómo | |
247 | construir el paquete, la que incluye una lista de otros paquetes necesarios | |
248 | para la construcción, y añadir @dfn{metadatos del paquete} junto a dicha | |
249 | receta, como la descripción y la información de licencias. | |
250 | ||
251 | En Guix toda esta información está contenida en @dfn{definiciones de | |
252 | paquete}. Las definiciones de paquete proporcionan una vista de alto nivel | |
253 | del paquete. Son escritas usando la sintaxis del lenguaje de programación | |
254 | Scheme; de hecho, definimos una variable por cada paquete enlazada a su | |
255 | definición y exportamos esa variable desde un módulo (@pxref{Módulos de paquetes}). No obstante, un conocimiento profundo de Scheme @emph{no} es un | |
256 | pre-requisito para la creación de paquetes. Para más información obre las | |
257 | definiciones de paquetes, @pxref{Definición de paquetes}. | |
258 | ||
259 | Una vez que una definición de paquete está en su lugar, almacenada en un | |
260 | fichero del árbol de fuentes de Guix, puede probarse usando la orden | |
261 | @command{guix build} (@pxref{Invocación de guix build}). Por ejemplo, asumiendo | |
262 | que el nuevo paquete se llama @code{gnuevo}, puede ejecutar esta orden desde | |
263 | el árbol de construcción de Guix (@pxref{Ejecución de Guix antes de estar instalado}): | |
264 | ||
265 | @example | |
266 | ./pre-inst-env guix build gnuevo --keep-failed | |
267 | @end example | |
268 | ||
269 | El uso de @code{--keep-failed} facilita la depuración de errores de | |
270 | construcción ya que proporciona acceso al árbol de la construcción | |
271 | fallida. Otra opción útil de línea de órdenes para la depuración es | |
272 | @code{--log-file}, para acceder al log de construcción. | |
273 | ||
274 | Si el paquete resulta desconocido para la orden @command{guix}, puede ser | |
275 | que el fichero fuente contenga un error de sintaxis, o no tenga una cláusula | |
276 | @code{define-public} para exportar la variable del paquete. Para encontrar | |
277 | el problema puede cargar el módulo desde Guile para obtener más información | |
278 | sobre el error real: | |
279 | ||
280 | @example | |
281 | ./pre-inst-env guile -c '(use-modules (gnu packages gnuevo))' | |
282 | @end example | |
283 | ||
284 | Una vez que se construya correctamente su paquete, por favor, envíenos un | |
285 | parche (@pxref{Envío de parches}). En cualquier caso, si necesita ayuda | |
286 | también estaremos felices de ayudarle. Una vez el parche se haya incorporado | |
287 | al repositorio de Guix, el nuevo paquete se construye automáticamente en las | |
288 | plataformas disponibles por @url{http://hydra.gnu.org/jobset/gnu/master, | |
289 | nuestro sistema de integración continua}. | |
290 | ||
291 | @cindex servidor de sustituciones | |
292 | Las usuarias pueden obtener la nueva definición de paquete ejecutando | |
293 | simplemente @command{guix pull} (@pxref{Invocación de guix pull}). Cuando | |
294 | @code{@value{SUBSTITUTE-SERVER}} ha terminado de construir el paquete, la | |
295 | instalación del paquete descarga automáticamente los binarios desde allí | |
296 | (@pxref{Sustituciones}). El único lugar donde la intervención humana es | |
297 | necesaria es en la revisión y aplicación del parche. | |
298 | ||
299 | ||
300 | @menu | |
301 | * Libertad del software:: Qué puede entrar en la distribución. | |
302 | * Nombrado de paquetes:: ¿Qué hay en un nombre? | |
303 | * Versiones numéricas:: Cuando el nombre no es suficiente. | |
304 | * Sinopsis y descripciones:: Ayudar a las usuarias a encontrar el paquete | |
305 | adecuado. | |
306 | * Módulos Python:: Un toque de comedia británica. | |
307 | * Módulos Perl:: Pequeñas perlas. | |
308 | * Paquetes Java:: La parada del café. | |
309 | * Tipografías:: Amor por las letras. | |
310 | @end menu | |
311 | ||
312 | @node Libertad del software | |
313 | @subsection Libertad del software | |
314 | ||
315 | @c =========================================================================== | |
316 | @c | |
317 | @c This file was generated with po4a. Translate the source file. | |
318 | @c | |
319 | @c =========================================================================== | |
320 | @c Adapted from http://www.gnu.org/philosophy/philosophy.html. | |
321 | @cindex software libre | |
322 | El sistema operativo GNU se ha desarrollado para que las usuarias puedan | |
323 | ejercitar su libertad de computación. GNU es @dfn{software libre}, lo que | |
324 | significa ue las usuarias tienen las | |
325 | @url{http://www.gnu.org/philosophy/free-sw.html,cuatro libertades | |
326 | esenciales}: para ejecutar el programa, para estudiar y modificar el | |
327 | programa en la forma de código fuente, para redistribuir copias exactas y | |
328 | para distribuir versiones modificadas. Los paquetes encontrados en la | |
329 | distribución GNU proporcionan únicamente software que permite estas cuatro | |
330 | libertades. | |
331 | ||
332 | Además, la distribución GNU sigue las | |
333 | @url{http://www.gnu.org/distros/free-system-distribution-guidelines.html,directrices | |
334 | de distribución de software libre}. Entre otras cosas, estas directrices | |
335 | rechazan firmware no-libre, recomendaciones de software no-libre y el | |
336 | tratamiento de formas de tratar con marcas registradas y patentes. | |
337 | ||
338 | Algunos paquetes originales, que serían de otra manera software libre, | |
339 | contienen un subconjunto pequeño y opcional que viola estas directrices, por | |
340 | ejemplo debido a que ese subconjunto sea en sí código no-libre. Cuando esto | |
341 | sucede, las partes indeseadas son eliminadas con parches o fragmentos de | |
342 | código en la forma @code{origin} del paquete (@pxref{Definición de paquetes}). De | |
343 | este modo, @code{guix build --source} devuelve las fuentes ``liberadas'' en | |
344 | vez de la versión original de las fuentes. | |
345 | ||
346 | ||
347 | @node Nombrado de paquetes | |
348 | @subsection Nombrado de paquetes | |
349 | ||
350 | @cindex nombre de paquete | |
351 | Un paquete tiene realmente dos nombres asociados con él: Primero, el nombre | |
352 | de la @emph{variable Scheme} asociada, que aparece después de | |
353 | @code{define-public}. A través de este nombre, el paquete está disponible en | |
354 | código Scheme, por ejemplo como entrada de otro paquete. Segundo, la cadena | |
355 | en el campo @code{name} de la definición de paquete. Este nombre se usa por | |
356 | las órdenes de gestión de paquetes como @command{guix package} y | |
357 | @command{guix build}. | |
358 | ||
359 | Ambos normalmente son iguales y corresponden a la conversión a minúsculas | |
360 | del nombre de proyecto elegido por sus creadoras, con los guiones bajos | |
361 | sustituidos por guiones. Por ejemplo, GNUnet está disponible como | |
362 | @code{gnunet}, y SDL_net como @code{sdl-net}. | |
363 | ||
364 | No añadimos prefijos @code{lib} para paquetes de bibliotecas, a menos que | |
365 | sean parte del nombre oficial del proyecto. Pero vea @ref{Módulos Python} y | |
366 | @ref{Módulos Perl} para reglas especiales que conciernen a los módulos de | |
367 | los lenguajes Python y Perl. | |
368 | ||
369 | Los nombres de paquetes de tipografías se manejan de forma diferente, | |
370 | @pxref{Tipografías}. | |
371 | ||
372 | ||
373 | @node Versiones numéricas | |
374 | @subsection Versiones numéricas | |
375 | ||
376 | @cindex versión de paquete | |
377 | Normalmente empaquetamos únicamente la última versión de un proyecto dado de | |
378 | software libre. Pero a veces, por ejemplo para versiones de bibliotecas | |
379 | incompatibles, se necesitan dos (o más) versiones del mismo paquete. Estas | |
380 | necesitan nombres diferentes para las variables Scheme. Usamos el nombre | |
381 | como se define en @ref{Nombrado de paquetes} para la versión más reciente; las | |
382 | versiones previas usan el mismo nombre, añadiendo un @code{-} y el prefijo | |
383 | menor del número de versión que permite distinguir las dos versiones. | |
384 | ||
385 | El nombre dentro de la definición de paquete es el mismo para todas las | |
386 | versiones de un paquete y no contiene ningún número de versión. | |
387 | ||
388 | Por ejemplo, las versiones 2.24.20 y 3.9.12 de GTK+ pueden empaquetarse como | |
389 | sigue: | |
390 | ||
391 | @example | |
392 | (define-public gtk+ | |
393 | (package | |
394 | (name "gtk+") | |
395 | (version "3.9.12") | |
396 | ...)) | |
397 | (define-public gtk+-2 | |
398 | (package | |
399 | (name "gtk+") | |
400 | (version "2.24.20") | |
401 | ...)) | |
402 | @end example | |
403 | Si también deseásemos GTK+3.8.2, se empaquetaría como | |
404 | @example | |
405 | (define-public gtk+-3.8 | |
406 | (package | |
407 | (name "gtk+") | |
408 | (version "3.8.2") | |
409 | ...)) | |
410 | @end example | |
411 | ||
412 | @c See <https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00425.html>, | |
413 | @c for a discussion of what follows. | |
414 | @cindex número de versión, para revisiones de VCS | |
415 | De manera ocasional, empaquetamos instantáneas del sistema de control de | |
416 | versiones (VCS) de las desarrolladoras originales en vez de publicaciones | |
417 | formales. Esto debería permanecer como algo excepcional, ya que son las | |
418 | desarrolladoras originales quienes deben clarificar cual es la entrega | |
419 | estable. No obstante, a veces es necesario. Por tanto, ¿qué deberíamos poner | |
420 | en el campo @code{version}? | |
421 | ||
422 | Claramente, tenemos que hacer visible el identificador de la revisión en el | |
423 | VCS en la cadena de versión, pero tamién debemos asegurarnos que la cadena | |
424 | de versión incrementa monotónicamente de manera que @command{guix package | |
425 | --upgrade} pueda determinar qué versión es más moderna. Ya que los | |
426 | identificadores de revisión, notablemente en Git, no incrementan | |
427 | monotónicamente, añadimos un número de revisión que se incrementa cada vez | |
428 | que actualizamos a una nueva instantánea. La versión que resulta debería ser | |
429 | así: | |
430 | ||
431 | @example | |
432 | 2.0.11-3.cabba9e | |
433 | ^ ^ ^ | |
434 | | | `-- ID de revisión original | |
435 | | | | |
436 | | `--- revisión del paquete Guix | |
437 | | | |
438 | última versión de publicación | |
439 | @end example | |
440 | ||
441 | Es una buena idea recortar los identificadores de revisión en el campo | |
442 | @code{version} a, digamos, 7 dígitos. Esto evita una molestia estética | |
443 | (asumiendo que la estética tiene importancia aquí) así como problemas | |
444 | relacionados con los límites del sistema operativo como la longitud máxima | |
445 | de una cadena de ejecución #! (127 bytes en el núcleo Linux). Es mejor usar | |
446 | el identificador de revisión completo en @code{origin}, no obstante, para | |
447 | evitar ambigüedades. Una definición típica de paquete sería así: | |
448 | ||
449 | @example | |
450 | (define mi-paquete | |
451 | (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7") | |
452 | (revision "1")) ;Revisión Guix del paquete | |
453 | (package | |
454 | (version (git-version "0.9" revision commit)) | |
455 | (source (origin | |
456 | (method git-fetch) | |
457 | (uri (git-reference | |
458 | (url "git://example.org/mi-paquete.git") | |
459 | (commit commit))) | |
460 | (sha256 (base32 "1mbikn@dots{}")) | |
461 | (file-name (git-file-name name version)))) | |
462 | ;; @dots{} | |
463 | ))) | |
464 | @end example | |
465 | ||
466 | @node Sinopsis y descripciones | |
467 | @subsection Sinopsis y descripciones | |
468 | ||
469 | @cindex descripción de paquete | |
470 | @cindex sinopsis de paquete | |
471 | Como hemos visto previamente, cada paquete en GNU@tie{}Guix incluye una | |
472 | sinopsis y una descripción (@pxref{Definición de paquetes}). Las sinopsis y | |
473 | descripciones son importantes: son en lo que @command{guix package --search} | |
474 | busca, y una pieza crucial de información para ayudar a las usuarias a | |
475 | determinar si un paquete dado cubre sus necesidades. Consecuentemente, las | |
476 | empaquetadoras deben prestar atención a qué se incluye en ellas. | |
477 | ||
478 | Las sinopsis deben empezar con mayúscula y no deben terminar con punto. No | |
479 | deben empezar con un artículo que habitualmente no aporta nada; por ejemplo, | |
480 | se prefiere ``Herramienta para chiribizar'' sobre ``Una herramienta que | |
481 | chiribiza ficheros''. La sinopsis debe decir qué es el paquete---por | |
482 | ejemplo, ``Utilidades básicas GNU (ficheros, texto, shell)''---o para qué se | |
483 | usa---por ejemplo, la sinopsis de GNU@tie{}grep es ``Imprime líneas que | |
484 | aceptadas por un patrón''. | |
485 | ||
486 | Tenga en cuenta que las sinopsis deben tener un claro significado para una | |
487 | audiencia muy amplia. Por ejemplo, ``Manipula la alineación en el formato | |
488 | SAM'' puede tener sentido para una investigadora de bioinformática con | |
489 | experiencia, pero puede ser de poca ayuda o incluso llevar a confusión a una | |
490 | audiencia no-especializada. Es una buena idea proporcionar una sinopsis que | |
491 | da una idea del dominio de aplicación del paquete. En ese ejemplo, esto | |
492 | podría ser algo como ``Manipula la alineación de secuencias de | |
493 | nucleótidos'', lo que esperablemente proporciona a la usuaria una mejor idea | |
494 | sobre si esto es lo que está buscando. | |
495 | ||
496 | Las descripciones deben tener entre cinco y diez líneas. Use frases | |
497 | completas, y evite usar acrónimos sin introducirlos previamente. Por favor | |
498 | evite frases comerciales como ``líder mundial'', ``de potencia industrial'' | |
499 | y ``siguiente generación'', y evite superlativos como ``el más | |
500 | avanzado''---no son útiles para las usuarias que buscan un paquete e incluso | |
501 | pueden sonar sospechosas. En vez de eso, intente ceñirse a los hechos, | |
502 | mencionando casos de uso y características. | |
503 | ||
504 | @cindex marcado Texinfo, en descripciones de paquetes | |
505 | Las descripciones pueden incluir marcado Texinfo, lo que es útil para | |
506 | introducir ornamentos como @code{@@code} o @code{@@dfn}, listas de puntos o | |
507 | enlaces (@pxref{Overview,,, texinfo, GNU Texinfo}). Por consiguiente, debe | |
508 | ser cuidadosa cuando use algunos caracteres, por ejemplo @samp{@@} y llaves, | |
509 | que son los caracteres especiales básicos en Texinfo (@pxref{Special | |
510 | Characters,,, texinfo, GNU Texinfo}). Las interfaces de usuaria como | |
511 | @command{guix package --show} se encargan de su correcta visualización. | |
512 | ||
513 | Las sinopsis y descripciones son traducidas por voluntarias | |
514 | @uref{http://translationproject.org/domain/guix-packages.html, en | |
515 | Translation Project} para que todas las usuarias posibles puedan leerlas en | |
516 | su lengua nativa. Las interfaces de usuaria las buscan y las muestran en el | |
517 | idioma especificado por la localización actual. | |
518 | ||
519 | Para permitir a @command{xgettext} extraerlas como cadenas traducibles, las | |
520 | sinopsis y descripciones @emph{deben ser cadenas literales}. Esto significa | |
521 | que no puede usar @code{string-append} o @code{format} para construir estas | |
522 | cadenas: | |
523 | ||
524 | @lisp | |
525 | (package | |
526 | ;; @dots{} | |
527 | (synopsis "Esto es traducible") | |
528 | (description (string-append "Esto " "*no*" " es traducible."))) | |
529 | @end lisp | |
530 | ||
531 | La traducción requiere mucho trabajo, por lo que, como empaquetadora, le | |
532 | rogamos que ponga incluso más atención a sus sinopsis y descripciones ya que | |
533 | cada cambio puede suponer trabajo adicional para las traductoras. Para | |
534 | ayudarlas, es posible hacer recomendaciones o instrucciones insertando | |
535 | comentarios especiales como este (@pxref{xgettext Invocation,,, gettext, GNU | |
536 | Gettext}): | |
537 | ||
538 | @example | |
539 | ;; TRANSLATORS: "X11 resize-and-rotate" should not be translated. | |
540 | (description "ARandR is designed to provide a simple visual front end | |
541 | for the X11 resize-and-rotate (RandR) extension. @dots{}") | |
542 | @end example | |
543 | ||
544 | ||
545 | @node Módulos Python | |
546 | @subsection Módulos Python | |
547 | ||
548 | @cindex python | |
549 | Actualmente empaquetamos Python 2 y Python 3, bajo los nombres de variable | |
550 | Scheme @code{python-2} y @code{python} como se explica en @ref{Versiones numéricas}. Para evitar confusiones y conflictos de nombres con otros | |
551 | lenguajes de programación, parece deseable que el nombre de paquete para un | |
552 | módulo Python contenga la palabra @code{python}. | |
553 | ||
554 | Algunos módulos son compatibles únicamente con una versión de Python, otros | |
555 | con ambas. Si el paquete Foo compila sólo con Python 3, lo llamamos | |
556 | @code{python-foo}; si compila sólo con Python 2, lo llamamos | |
557 | @code{python2-foo}. Si es compatible con ambas versiones, creamos dos | |
558 | paquetes con los nombres correspondientes. | |
559 | ||
560 | Si un proyecto ya contiene la palabra @code{python}, la eliminamos; por | |
561 | ejemplo, el módulo python-dateutil se empaqueta con los nombres | |
562 | @code{python-dateutil} y @code{python2-dateutil}. Si el nombre del proyecto | |
563 | empieza con @code{py} (por ejemplo @code{pytz}), este se mantiene y el | |
564 | prefijo es el especificado anteriormente.. | |
565 | ||
566 | @subsubsection Especificación de dependencias | |
567 | @cindex entradas, para paquetes Python | |
568 | ||
569 | La información de dependencias para paquetes Python está disponible | |
570 | habitualmente en el árbol de fuentes, con varios grados de precisión: en el | |
571 | fichero @file{setup.py}, en @file{requirements.txt} o en @file{tox.ini}. | |
572 | ||
573 | Su misión, cuando escriba una receta para un paquete Python, es asociar | |
574 | estas dependencias con el tipo apropiado de ``entrada'' (@pxref{Referencia de ``package'', inputs}). Aunque el importador de @code{pypi} normalmente hace un | |
575 | buen trabajo (@pxref{Invocación de guix import}), puede querer comprobar la | |
576 | siguiente lista para determinar qué dependencia va dónde. | |
577 | ||
578 | @itemize | |
579 | ||
580 | @item | |
581 | Actualmente empaquetamos con @code{setuptools} y @code{pip} instalados como | |
582 | Python 3.4 tiene por defecto. Por tanto no necesita especificar ninguno de | |
583 | ellos como entrada. @command{guix lint} le avisará si lo hace. | |
584 | ||
585 | @item | |
586 | Las dependencias Python requeridas en tiempo de ejecución van en | |
587 | @code{propagated-inputs}. Típicamente están definidas con la palabra clave | |
588 | @code{install_requires} en @file{setup.py}, o en el fichero | |
589 | @file{requirements.txt}. | |
590 | ||
591 | @item | |
592 | Los paquetes Python requeridos únicamente durante la construcción---por | |
593 | ejemplo, aquellos listados con la palabra clave @code{setup_requires} en | |
594 | @file{setup.py}---o únicamente para pruebas---por ejemplo, aquellos en | |
595 | @code{tests_require}---van en @code{native-inputs}. La razón es que (1) no | |
596 | necesitan ser propagados ya que no se requieren en tiempo de ejecución, y | |
597 | (2) en un entorno de compilación cruzada lo que necesitamos es la entrada | |
598 | ``nativa''. | |
599 | ||
600 | Ejemplos son las bibliotecas de pruebas @code{pytest}, @code{mock} y | |
601 | @code{nose}. Por supuesto, si alguno de estos paquetes también se necesita | |
602 | en tiempo de ejecución, necesita ir en @code{propagated-inputs}. | |
603 | ||
604 | @item | |
605 | Todo lo que no caiga en las categorías anteriores va a @code{inputs}, por | |
606 | ejemplo programas o bibliotecas C requeridas para construir los paquetes | |
607 | Python que contienen extensiones C. | |
608 | ||
609 | @item | |
610 | Si un paquete Python tiene dependencias opcionales (@code{extras_require}), | |
611 | queda en su mano decidir si las añade o no, en base a la relación | |
612 | utilidad/sobrecarga (@pxref{Envío de parches, @command{guix size}}). | |
613 | ||
614 | @end itemize | |
615 | ||
616 | ||
617 | @node Módulos Perl | |
618 | @subsection Módulos Perl | |
619 | ||
620 | @cindex perl | |
621 | Los programas ejecutables Perl se nombran como cualquier otro paquete, | |
622 | mediante el uso del nombre oficial en minúsculas. Para paquetes Perl que | |
623 | contienen una única clase, usamos el nombre en minúsculas de la clase, | |
624 | substituyendo todas las ocurrencias de @code{::} por guiones y agregando el | |
625 | prefijo @code{perl-}. Por tanto la clase @code{XML::Parser} se convierte en | |
626 | @code{perl-xml-parser}. Los módulos que contienen varias clases mantienen su | |
627 | nombre oficial en minúsculas y también se agrega @code{perl-} al | |
628 | inicio. Dichos módulos tienden a tener la palabra @code{perl} en alguna | |
629 | parte de su nombre, la cual se elimina en favor del prefijo. Por ejemplo, | |
630 | @code{libwww-perl} se convierte en @code{perl-libwww}. | |
631 | ||
632 | ||
633 | @node Paquetes Java | |
634 | @subsection Paquetes Java | |
635 | ||
636 | @cindex java | |
637 | Los programas Java ejecutables se nombran como cualquier otro paquete, | |
638 | mediante el uso del nombre oficial en minúsculas. | |
639 | ||
640 | Para evitar confusión y colisiones de nombres con otros lenguajes de | |
641 | programación, es deseable que el nombre del paquete para un paquete Java | |
642 | contenga el prefijo @code{java-}. Si el proyecto ya tiene la palabra | |
643 | @code{java}, eliminamos esta; por ejemplo, el paquete @code{ngsjaga} se | |
644 | empaqueta bajo el nombre @code{java-ngs}. | |
645 | ||
646 | Para los paquetes Java que contienen una clase única o una jerarquía | |
647 | pequeña, usamos el nombre de clase en minúsculas, substituyendo todas las | |
648 | ocurrencias de @code{.} por guiones y agregando el prefijo @code{java-}. Por | |
649 | tanto la clase @code{apache.commons.cli} se convierte en el paquete | |
650 | @code{java-apache-commons-cli}. | |
651 | ||
652 | ||
653 | @node Tipografías | |
654 | @subsection Tipografías | |
655 | ||
656 | @cindex tipografías | |
657 | Para tipografías que no se instalan generalmente por una usuaria para | |
658 | propósitos tipográficos, o que se distribuyen como parte de un paquete de | |
659 | software más grande, seguimos las reglas generales de empaquetamiento de | |
660 | software; por ejemplo, esto aplica a las tipografías distribuidas como parte | |
661 | del sistema X.Org o las tipografías que son parte de TeX Live. | |
662 | ||
663 | Para facilitar a las usuarias la búsqueda de tipografías, los nombres para | |
664 | otros paquetes que contienen únicamente tipografías se construyen como | |
665 | sigue, independientemente del nombre de paquete oficial. | |
666 | ||
667 | El nombre de un paquete que contiene únicamente una familia tipográfica | |
668 | comienza con @code{font-}; seguido por el nombre de la tipografía y un guión | |
669 | si la tipografía es conocida, y el nombre de la familia tipográfica, donde | |
670 | los espacios se sustituyen por guiones (y como es habitual, todas las letras | |
671 | mayúsculas se transforman a minúsculas). Por ejemplo, la familia de | |
672 | tipografías Gentium de SIL se empaqueta bajo el nombre de | |
673 | @code{font-sil-gentium}. | |
674 | ||
675 | Para un paquete que contenga varias familias tipográficas, el nombre de la | |
676 | colección se usa en vez del nombre de la familia tipográfica. Por ejemplo, | |
677 | las tipografías Liberation consisten en tres familias: Liberation Sans, | |
678 | Liberation Serif y Liberation Mono. Estas se podrían empaquetar por separado | |
679 | bajo los nombres @code{font-liberation-sans}, etcétera; pero como se | |
680 | distribuyen de forma conjunta bajo un nombre común, preferimos empaquetarlas | |
681 | conjuntamente como @code{font-liberation}. | |
682 | ||
683 | En el caso de que varios formatos de la misma familia o colección | |
684 | tipográfica se empaqueten de forma separada, una forma corta del formato, | |
685 | precedida por un guión, se añade al nombre del paquete. Usamos @code{-ttf} | |
686 | para tipografías TrueType, @code{-otf} para tipografías OpenType y | |
687 | @code{-type1} para tipografías Tipo 1 PostScript. | |
688 | ||
689 | ||
690 | @node Estilo de codificación | |
691 | @section Estilo de codificación | |
692 | ||
693 | En general nuestro código sigue los Estándares de codificación GNU | |
694 | (@pxref{Top,,, standards, GNU Coding Standards}). No obstante, no dicen | |
695 | mucho de Scheme, así que aquí están algunas reglas adicionales. | |
696 | ||
697 | @menu | |
698 | * Paradigma de programación:: Cómo componer sus elementos. | |
699 | * Módulos:: ¿Dónde almacenar su código? | |
700 | * Tipos de datos y reconocimiento de patrones:: Implementación de | |
701 | estructuras de datos. | |
702 | * Formato del código:: Convenciones de escritura. | |
703 | @end menu | |
704 | ||
705 | @node Paradigma de programación | |
706 | @subsection Paradigma de programación | |
707 | ||
708 | El código scheme en Guix está escrito en un estilo puramente funcional. Una | |
709 | excepción es el código que incluye entrada/salida, y procedimientos que | |
710 | implementan conceptos de bajo nivel, como el procedimiento @code{memoize}. | |
711 | ||
712 | @node Módulos | |
713 | @subsection Módulos | |
714 | ||
715 | Los módulos Guile que están destinados a ser usados en el lado del | |
716 | constructor deben encontrarse en el espacio de nombres @code{(guix build | |
717 | @dots{})}. No deben hacer referencia a otros módulos Guix o GNU. No | |
718 | obstante, no hay problema en usar un módulo del lado del constructor en un | |
719 | módulo ``del lado del cliente''. | |
720 | ||
721 | Los módulos que tratan con el sistema GNU más amplio deben estar en el | |
722 | espacio de nombres @code{(gnu @dots{})} en vez de en @code{(guix @dots{})}. | |
723 | ||
724 | @node Tipos de datos y reconocimiento de patrones | |
725 | @subsection Tipos de datos y reconocimiento de patrones | |
726 | ||
727 | La tendencia en el Lisp clásico es usar listas para representar todo, y | |
728 | recorrerlas ``a mano'' usando @code{car}, @code{cdr}, @code{cadr} y | |
729 | compañía. Hay varios problemas con este estilo, notablemente el hecho de que | |
730 | es difícil de leer, propenso a errores y una carga para informes adecuados | |
731 | de errores de tipado. | |
732 | ||
733 | El código de Guix debe definir tipos de datos apropiados (por ejemplo, | |
734 | mediante el uso @code{define-record-type*}) en vez de abusar de las | |
735 | listas. Además debe usarse el reconocimiento de patrones, vía el módulo de | |
736 | Guile @code{(ice-9 match)}, especialmente cuando se analizan listas. | |
737 | ||
738 | @node Formato del código | |
739 | @subsection Formato del código | |
740 | ||
741 | @cindex dar formato al código | |
742 | @cindex estilo de codificación | |
743 | Cuando escribimos código Scheme, seguimos la sabiduría común entre las | |
744 | programadoras Scheme. En general, seguimos las | |
745 | @url{http://mumble.net/~campbell/scheme/style.txt, Reglas de estilo Lisp de | |
746 | Riastradh}. Este documento resulta que también describe las convenciones más | |
747 | usadas en el código Guile. Está lleno de ideas y bien escrito, así que | |
748 | recomendamos encarecidamente su lectura. | |
749 | ||
750 | Algunas formas especiales introducidas en Guix, como el macro | |
751 | @code{substitute*} tienen reglas de indentación especiales. Estas están | |
752 | definidas en el fichero @file{.dir-locals.el}, el cual Emacs usa | |
753 | automáticamente. Fíjese que además Emacs-Guix proporciona el modo | |
754 | @code{guix-devel-mode} que indenta y resalta adecuadamente el código de Guix | |
755 | (@pxref{Desarrollo,,, emacs-guix, The Emacs-Guix Reference Manual}). | |
756 | ||
757 | @cindex indentación, de código | |
758 | @cindex formato, de código | |
759 | Si no usa Emacs, por favor asegúrese de que su editor conoce esas | |
760 | reglas. Para indentar automáticamente una definición de paquete también | |
761 | puede ejecutar: | |
762 | ||
763 | @example | |
764 | ./etc/indent-code.el gnu/packages/@var{fichero}.scm @var{paquete} | |
765 | @end example | |
766 | ||
767 | @noindent | |
768 | Esto indenta automáticamente la definición de @var{paquete} en | |
769 | @file{gnu/packages/@var{fichero}.scm} ejecutando Emacs en modo de | |
770 | procesamiento de lotes. Para indentar un fichero completo, omita el segundo | |
771 | parámetro: | |
772 | ||
773 | @example | |
774 | ./etc/indent-code.el gnu/services/@var{fichero}.scm | |
775 | @end example | |
776 | ||
777 | @cindex Vim, edición de código Scheme | |
778 | Si está editando código con Vim, le recomendamos ejecutar @code{:set | |
779 | autoindent} para que el código se indente automáticamente mientras | |
780 | escribe. Adicionalmente, | |
781 | @uref{https://www.vim.org/scripts/script.php?script_id=3998, | |
782 | @code{paredit.vim}} puede ayudar a manejar todos estos paréntesis. | |
783 | ||
784 | Requerimos que todos los procedimientos del nivel superior tengan una cadena | |
785 | de documentación. Este requisito puede relajarse para procedimientos simples | |
786 | privados en el espacio de nombres @code{(guix build @dots{})} no obstante. | |
787 | ||
788 | Los procedimientos no deben tener más de cuatro parámetros posicionales. Use | |
789 | parámetros con palabras clave para procedimientos que toman más de cuatro | |
790 | parámetros. | |
791 | ||
792 | ||
793 | @node Envío de parches | |
794 | @section Envío de parches | |
795 | ||
796 | El desarrollo se lleva a cabo usando el sistema de control de versiones | |
797 | distribuido Git. Por lo tanto, no es estrictamente necesario el acceso al | |
798 | repositorio. Son bienvenidas las contribuciones en forma de parches como los | |
799 | producidos por @code{git format-patch} enviadas a la lista de correo | |
800 | @email{guix-patches@@gnu.org}. | |
801 | ||
802 | Esta lista de correo está respaldada por una instancia de Debbugs accesible | |
803 | en @uref{https://bugs.gnu.org/guix-patches}, la cual nos permite mantener el | |
804 | seguimiento de los envíos. A cada mensaje enviado a esa lista de correo se | |
805 | le asigna un número de seguimiento; la gente puede realizar aportaciones | |
806 | sobre el tema mediante el envío de correos electrónicos a | |
807 | @code{@var{NNN}@@debbugs.gnu.org}, donde @var{NNN} es el número de | |
808 | seguimiento (@pxref{Envío de una serie de parches}). | |
809 | ||
810 | Le rogamos que escriba los mensajes de revisiones en formato ChangeLog | |
811 | (@pxref{Change Logs,,, standards, GNU Coding Standards}); puede comprobar la | |
812 | historia de revisiones en busca de ejemplos. | |
813 | ||
814 | Antes de enviar un parche que añade o modifica una definición de un paquete, | |
815 | por favor recorra esta lista de comprobaciones: | |
816 | ||
817 | @enumerate | |
818 | @item | |
819 | Si las autoras del paquete software proporcionan una firma criptográfica | |
820 | para el archivo de la versión, haga un esfuerzo para verificar la | |
821 | autenticidad del archivo. Para un fichero de firma GPG separado esto puede | |
822 | hacerse con la orden @code{gpg --verify}. | |
823 | ||
824 | @item | |
825 | Dedique algún tiempo a proporcionar una sinopsis y descripción adecuadas | |
826 | para el paquete. @xref{Sinopsis y descripciones}, para algunas directrices. | |
827 | ||
828 | @item | |
829 | Ejecute @code{guix lint @var{paquete}}, donde @var{paquete} es el nombre del | |
830 | paquete nuevo o modificado, y corrija cualquier error del que informe | |
831 | (@pxref{Invocación de guix lint}). | |
832 | ||
833 | @item | |
834 | Asegurese de que el paquete compile en su plataforma, usando @code{guix | |
835 | build @var{package}}. | |
836 | ||
837 | @item | |
838 | También le recomendamos que pruebe a construir el paquete en otras | |
839 | plataformas disponibles. Como puede no disponer de acceso a dichas | |
840 | plataformas hardware físicamente, le recomendamos el uso de | |
841 | @code{qemu-binfmt-service-type} para emularlas. Para activarlo, añada el | |
842 | siguiente servicio a la lista de servicios en su configuración | |
843 | @code{operating-system}: | |
844 | ||
845 | @example | |
846 | (service qemu-binfmt-service-type | |
847 | (qemu-binfmt-configuration | |
848 | (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el")) | |
849 | (guix-support? #t))) | |
850 | @end example | |
851 | ||
852 | Una vez hecho esto, reconfigure su sistema. | |
853 | ||
854 | Enotonces podrá construir paquetes para diferentes plataformas mediante la | |
855 | opción @code{--system}. Por ejemplo, para la construcción del paquete | |
856 | "hello" para las arquitecturas armhf, aarch64 o mips64 ejecutaría las | |
857 | siguientes órdenes, respectivamente: | |
858 | @example | |
859 | guix build --system=armhf-linux --rounds=2 hello | |
860 | guix build --system=aarch64-linux --rounds=2 hello | |
861 | guix build --system=mips64el-linux --rounds=2 hello | |
862 | @end example | |
863 | ||
864 | @item | |
865 | @cindex empaquetamientos | |
866 | Asegurese de que el paquete no usa copias empaquetadas de software ya | |
867 | disponible como paquetes separados. | |
868 | ||
869 | A veces, paquetes incluyen copias embebidas del código fuente de sus | |
870 | dependencias para conveniencia de las usuarias. No obstante, como | |
871 | distribución, queremos asegurar que dichos paquetes efectivamente usan la | |
872 | copia que ya tenemos en la distribución si hay ya una. Esto mejora el uso de | |
873 | recursos (la dependencia es construida y almacenada una sola vez), y permite | |
874 | a la distribución hacer cambios transversales como aplicar actualizaciones | |
875 | de seguridad para un software dado en un único lugar y que afecte a todo el | |
876 | sistema---algo que esas copias embebidas impiden. | |
877 | ||
878 | @item | |
879 | Eche un vistazo al perfil mostrado por @command{guix size} (@pxref{Invocación de guix size}). Esto le permitirá darse cuenta de referencias a otros paquetes | |
880 | retenidas involuntariamente. También puede ayudar a determinar si se debe | |
881 | dividir el paquete (@pxref{Paquetes con múltiples salidas}), y qué | |
882 | dependencias opcionales deben usarse. En particular, evite añadir | |
883 | @code{texlive} como una dependencia: debido a su tamaño extremo, use | |
884 | @code{texlive-tiny} o @code{texlive-union}. | |
885 | ||
886 | @item | |
887 | Para cambios importantes, compruebe que los paquetes dependientes (si | |
888 | aplica) no se ven afectados por el cambio; @code{guix refresh | |
889 | --list-dependent @var{package}} le ayudará a hacerlo (@pxref{Invocación de guix refresh}). | |
890 | ||
891 | @c See <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>. | |
892 | @cindex estrategia de ramas | |
893 | @cindex estrategia de planificación de reconstrucciones | |
894 | En base al número de paquetes dependientes y, por tanto, del tamaño de la | |
895 | reconstrucción inducida, los revisiones van a ramas separadas, según estas | |
896 | líneas: | |
897 | ||
898 | @table @asis | |
899 | @item 300 paquetes dependientes o menos | |
900 | rama @code{master} (cambios no disruptivos). | |
901 | ||
902 | @item entre 300 y 1.200 paquetes dependientes | |
903 | rama @code{staging} (cambios no disruptivos). Esta rama está pensada para | |
904 | ser incorporada en @code{master} cada 3 semanas más o menos. Ramas temáticas | |
905 | (por ejemplo, una actualización de la pila de GNOME) pueden ir en una rama | |
906 | específica (digamos, @code{gnome-updates}). | |
907 | ||
908 | @item más de 1.200 paquetes dependientes | |
909 | rama @code{core-updates} (puede incluir cambios mayores y potencialmente | |
910 | disruptivos). Esta rama está pensada para ser incluida en @code{master} cada | |
911 | 2,5 más o menos. | |
912 | @end table | |
913 | ||
914 | Todas estas ramas son @uref{https://hydra.gnu.org/project/gnu, seguidas por | |
915 | nuestra granja de construcción} e incluidas en @code{master} una vez todo se | |
916 | ha construido satisfactoriamente. Esto nos permite corregir errores antes de | |
917 | que afecten a usuarias, y reducir la ventana durante la cual los binarios | |
918 | preconstruidos no están disponibles. | |
919 | ||
920 | @c TODO: It would be good with badges on the website that tracks these | |
921 | @c branches. Or maybe even a status page. | |
922 | Generalmente, ramas distintas a @code{master} se consideran | |
923 | @emph{congeladas} si ha habido una evaluación reciente, o hay una rama | |
924 | @code{-next} correspondiente. Por favor, pregunte en la lista de correo o en | |
925 | IRC si no está segura de dónde colocar un parche. | |
926 | ||
927 | @item | |
928 | @cindex determinismo, del proceso de construcción | |
929 | @cindex construcciones reproducibles, comprobar | |
930 | Compruebe si el proceso de construcción de un paquete es determinista. Esto | |
931 | significa típicamente comprobar si una construcción independiente del | |
932 | paquete ofrece exactamente el mismo resultado que usted obtuvo, bit a bit. | |
933 | ||
934 | Una forma simple de hacerlo es construyendo el mismo paquete varias veces | |
935 | seguidas en su máquina (@pxref{Invocación de guix build}): | |
936 | ||
937 | @example | |
938 | guix build --rounds=2 mi-paquete | |
939 | @end example | |
940 | ||
941 | Esto es suficiente una clase común de problemas de no-determinismo, como las | |
942 | marcas de tiempo o salida generada aleatoriamente en el resultado de la | |
943 | construcción. | |
944 | ||
945 | Otra opción es el uso de @command{guix challenge} (@pxref{Invocación de guix challenge}). Puede ejecutarse una vez la revisión del paquete haya sido | |
946 | publicada y construida por @code{@value{SUBSTITUTE-SERVER}} para comprobar | |
947 | si obtuvo el mismo resultado que usted. Mejor aún: encuentre otra máquina | |
948 | que pueda construirla y ejecute @command{guix publish}. Ya que la máquina | |
949 | remota es probablemente diferente a la suya, puede encontrar problemas de | |
950 | no-determinismo relacionados con el hardware---por ejemplo, el uso de un | |
951 | conjunto de instrucciones extendido diferente---o con el núcleo del sistema | |
952 | operativo---por ejemplo, dependencias en @code{uname} o ficheros | |
953 | @file{/proc}. | |
954 | ||
955 | @item | |
956 | Cuando escriba documentación, por favor use construcciones neutrales de | |
957 | género para referirse a la gente@footnote{NdT: En esta traducción se ha | |
958 | optado por usar el femenino para referirse a @emph{personas}, ya que es el | |
959 | género gramatical de dicha palabra. Aunque las construcciones impersonales | |
960 | pueden adoptarse en la mayoría de casos, también pueden llegar a ser muy | |
961 | artificiales en otros usos del castellano; en ocasiones son directamente | |
962 | imposibles. Algunas construcciones que proponen la neutralidad de género | |
963 | dificultan la lecura automática (-x), o bien dificultan la corrección | |
964 | automática (-e), o bien aumentan significativamente la redundancia y reducen | |
965 | del mismo modo la velocidad en la lectura (-as/os, -as y -os). No obstante, | |
966 | la adopción del genero neutro heredado del latín, el que en castellano se ha | |
967 | unido con el masculino, como construcción neutral de género se considera | |
968 | inaceptable, ya que sería equivalente al ``it'' en inglés, nada más lejos de | |
969 | la intención de las autoras originales del texto.}, como | |
970 | @uref{https://en.wikipedia.org/wiki/Singular_they, singular ``they''@comma{} | |
971 | ``their''@comma{} ``them''} y demás. | |
972 | ||
973 | @item | |
974 | Compruebe que su parche contiene únicamente un conjunto relacionado de | |
975 | cambios. Agrupando cambios sin relación dificulta y ralentiza la revisión. | |
976 | ||
977 | Ejemplos de cambios sin relación incluyen la adición de varios paquetes, o | |
978 | una actualización de un paquete junto a correcciones a ese paquete. | |
979 | ||
980 | @item | |
981 | Por favor, siga nuestras reglas de formato de código, posiblemente | |
982 | ejecutando el guión @command{etc/indent-code.el} para que lo haga | |
983 | automáticamente por usted (@pxref{Formato del código}). | |
984 | ||
985 | @item | |
986 | Cuando sea posible, use espejos en la URL de las fuentes (@pxref{Invocación de guix download}). Use URL fiables, no generadas. Por ejemplo, los archivos de | |
987 | GitHub no son necesariamente idénticos de una generación a la siguiente, así | |
988 | que en este caso es normalmente mejor clonar el repositorio. No use el campo | |
989 | @command{name} en la URL: no es muy útil y si el nombre cambia, la URL | |
990 | probablemente estará mal. | |
991 | ||
992 | @end enumerate | |
993 | ||
994 | Cuando publique un parche a la lista de correo, use @samp{[PATCH] @dots{}} | |
995 | como el asunto. Puede usar su cliente de correo o la orden @command{git | |
996 | send-email} (@pxref{Envío de una serie de parches}). Preferimos recibir los parches | |
997 | en texto plano, ya sea en línea o como adjuntos MIME. Se le recomienda que | |
998 | preste atención por si su cliente de correo cambia algo como los saltos de | |
999 | línea o la indentación, lo que podría potencialmente romper los parches. | |
1000 | ||
1001 | Cuando un error es resuelto, por favor cierre el hilo enviando un correo a | |
1002 | @email{@var{NNN}-done@@debbugs.gnu.org}. | |
1003 | ||
1004 | @unnumberedsubsec Envío de una serie de parches | |
1005 | @anchor{Envío de una serie de parches} | |
1006 | @cindex series de parches | |
1007 | @cindex @code{git send-email} | |
1008 | @cindex @code{git-send-email} | |
1009 | ||
1010 | @c Debbugs bug: https://debbugs.gnu.org/db/15/15361.html | |
1011 | Cuando envíe una serie de parches (por ejemplo, usando @code{git | |
1012 | send-email}), por favor mande primero un mensaje a | |
1013 | @email{guix-patches@@gnu.org}, y después mande los parches siguientes a | |
1014 | @email{@var{NNN}@@debbugs.gnu.org} para asegurarse de que se mantienen | |
1015 | juntos. Véase @uref{https://debbugs.gnu.org/Advanced.html, la documentación | |
1016 | de Debbugs} para más información. |