4 This project is a cooperative effort, and we need your help to make it
5 grow! Please get in touch with us on @email{guix-devel@@gnu.org} and
6 @code{#guix} on the Freenode IRC network. We welcome ideas, bug
7 reports, patches, and anything that may be helpful to the project. We
8 particularly welcome help on packaging (@pxref{Packaging Guidelines}).
10 @cindex code of conduct, of contributors
11 @cindex contributor covenant
12 We want to provide a warm, friendly, and harassment-free environment, so
13 that anyone can contribute to the best of their abilities. To this end
14 our project uses a ``Contributor Covenant'', which was adapted from
15 @url{https://contributor-covenant.org/}. You can find a local version in
16 the @file{CODE-OF-CONDUCT} file in the source tree.
18 Contributors are not required to use their legal name in patches and
19 on-line communication; they can use any name or pseudonym of their
23 * Building from Git:: The latest and greatest.
24 * Running Guix Before It Is Installed:: Hacker tricks.
25 * The Perfect Setup:: The right tools.
26 * Packaging Guidelines:: Growing the distribution.
27 * Coding Style:: Hygiene of the contributor.
28 * Submitting Patches:: Share your work.
29 * Tracking Bugs and Patches:: Using Debbugs.
30 * Commit Access:: Pushing to the official repository.
31 * Updating the Guix Package:: Updating the Guix package definition.
34 @node Building from Git
35 @section Building from Git
37 If you want to hack Guix itself, it is recommended to use the latest
38 version from the Git repository:
41 git clone https://git.savannah.gnu.org/git/guix.git
44 @cindex authentication, of a Guix checkout
45 How do you ensure that you obtained a genuine copy of the repository?
46 To do that, run @command{guix git authenticate}, passing it the commit
47 and OpenPGP fingerprint of the @dfn{channel introduction}
48 (@pxref{Invoking guix git authenticate}):
50 @c The commit and fingerprint below must match those of the channel
51 @c introduction in '%default-channels'.
53 git fetch origin keyring:keyring
54 guix git authenticate 9edb3f66fd807b096b48283debdcddccfea34bad \
55 "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA"
59 This command completes with exit code zero on success; it prints an
60 error message and exits with a non-zero code otherwise.
62 As you can see, there is a chicken-and-egg problem: you first need to
63 have Guix installed. Typically you would install Guix System
64 (@pxref{System Installation}) or Guix on top of another distro
65 (@pxref{Binary Installation}); in either case, you would verify the
66 OpenPGP signature on the installation medium. This ``bootstraps'' the
69 The easiest way to set up a development environment for Guix is, of
70 course, by using Guix! The following command starts a new shell where
71 all the dependencies and appropriate environment variables are set up to
75 guix environment guix --pure
78 @xref{Invoking guix environment}, for more information on that command.
80 If you are unable to use Guix when building Guix from a checkout, the
81 following are the required packages in addition to those mentioned in the
82 installation instructions (@pxref{Requirements}).
85 @item @url{https://gnu.org/software/autoconf/, GNU Autoconf};
86 @item @url{https://gnu.org/software/automake/, GNU Automake};
87 @item @url{https://gnu.org/software/gettext/, GNU Gettext};
88 @item @url{https://gnu.org/software/texinfo/, GNU Texinfo};
89 @item @url{https://www.graphviz.org/, Graphviz};
90 @item @url{https://www.gnu.org/software/help2man/, GNU Help2man (optional)}.
93 On Guix, extra dependencies can be added by instead running @command{guix
94 environment} with @option{--ad-hoc}:
97 guix environment guix --pure --ad-hoc help2man git strace
100 Run @command{./bootstrap} to generate the build system infrastructure
101 using Autoconf and Automake. If you get an error like this one:
104 configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
108 it probably means that Autoconf couldn’t find @file{pkg.m4}, which is
109 provided by pkg-config. Make sure that @file{pkg.m4} is available. The
110 same holds for the @file{guile.m4} set of macros provided by Guile. For
111 instance, if you installed Automake in @file{/usr/local}, it wouldn’t
112 look for @file{.m4} files in @file{/usr/share}. In that case, you have
113 to invoke the following command:
116 export ACLOCAL_PATH=/usr/share/aclocal
119 @xref{Macro Search Path,,, automake, The GNU Automake Manual}, for
122 Then, run @command{./configure} as usual. Make sure to pass
123 @code{--localstatedir=@var{directory}} where @var{directory} is the
124 @code{localstatedir} value used by your current installation (@pxref{The
125 Store}, for information about this), usually @file{/var}. Note that you
126 will probably not run @command{make install} at the end (you don't have
127 to) but it's still important to pass the right @code{localstatedir}.
129 Finally, you have to invoke @code{make check} to run tests
130 (@pxref{Running the Test Suite}). If anything
131 fails, take a look at installation instructions (@pxref{Installation})
132 or send a message to the @email{guix-devel@@gnu.org, mailing list}.
134 From there on, you can authenticate all the commits included in your
141 The first run takes a couple of minutes, but subsequent runs are faster.
143 Or, when your configuration for your local Git repository doesn't match
144 the default one, you can provide the reference for the @code{keyring}
145 branch through the variable @code{GUIX_GIT_KEYRING}. The following
146 example assumes that you have a Git remote called @samp{myremote}
147 pointing to the official repository:
150 make authenticate GUIX_GIT_KEYRING=myremote/keyring
154 You are advised to run @command{make authenticate} after every
155 @command{git pull} invocation. This ensures you keep receiving valid
156 changes to the repository.
160 @node Running Guix Before It Is Installed
161 @section Running Guix Before It Is Installed
163 In order to keep a sane working environment, you will find it useful to
164 test the changes made in your local source tree checkout without
165 actually installing them. So that you can distinguish between your
166 ``end-user'' hat and your ``motley'' costume.
168 To that end, all the command-line tools can be used even if you have not
169 run @code{make install}. To do that, you first need to have an environment
170 with all the dependencies available (@pxref{Building from Git}), and then
171 simply prefix each command with
172 @command{./pre-inst-env} (the @file{pre-inst-env} script lives in the
173 top build tree of Guix; it is generated by @command{./configure}).
174 As an example, here is how you would build the @code{hello} package as
175 defined in your working tree (this assumes @command{guix-daemon} is
176 already running on your system; it's OK if it's a different version):
179 $ ./pre-inst-env guix build hello
183 Similarly, an example for a Guile session using the Guix modules:
186 $ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
193 @cindex read-eval-print loop
194 @dots{} and for a REPL (@pxref{Using Guile Interactively,,, guile, Guile
198 $ ./pre-inst-env guile
199 scheme@@(guile-user)> ,use(guix)
200 scheme@@(guile-user)> ,use(gnu)
201 scheme@@(guile-user)> (define snakes
203 (lambda (package lst)
204 (if (string-prefix? "python"
205 (package-name package))
209 scheme@@(guile-user)> (length snakes)
213 If you are hacking on the daemon and its supporting code or if
214 @command{guix-daemon} is not already running on your system, you can
215 launch it straight from the build tree@footnote{The @option{-E} flag to
216 @command{sudo} guarantees that @code{GUILE_LOAD_PATH} is correctly set
217 such that @command{guix-daemon} and the tools it uses can find the Guile
221 $ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
224 The @command{pre-inst-env} script sets up all the environment variables
225 necessary to support this, including @env{PATH} and @env{GUILE_LOAD_PATH}.
227 Note that @command{./pre-inst-env guix pull} does @emph{not} upgrade the
228 local source tree; it simply updates the @file{~/.config/guix/current}
229 symlink (@pxref{Invoking guix pull}). Run @command{git pull} instead if
230 you want to upgrade your local source tree.
233 @node The Perfect Setup
234 @section The Perfect Setup
236 The Perfect Setup to hack on Guix is basically the perfect setup used
237 for Guile hacking (@pxref{Using Guile in Emacs,,, guile, Guile Reference
238 Manual}). First, you need more than an editor, you need
239 @url{https://www.gnu.org/software/emacs, Emacs}, empowered by the
240 wonderful @url{https://nongnu.org/geiser/, Geiser}. To set that up, run:
243 guix package -i emacs guile emacs-geiser
246 Geiser allows for interactive and incremental development from within
247 Emacs: code compilation and evaluation from within buffers, access to
248 on-line documentation (docstrings), context-sensitive completion,
249 @kbd{M-.} to jump to an object definition, a REPL to try out your code,
250 and more (@pxref{Introduction,,, geiser, Geiser User Manual}). For
251 convenient Guix development, make sure to augment Guile’s load path so
252 that it finds source files from your checkout:
255 ;; @r{Assuming the Guix checkout is in ~/src/guix.}
256 (with-eval-after-load 'geiser-guile
257 (add-to-list 'geiser-guile-load-path "~/src/guix"))
260 To actually edit the code, Emacs already has a neat Scheme mode. But in
261 addition to that, you must not miss
262 @url{https://www.emacswiki.org/emacs/ParEdit, Paredit}. It provides
263 facilities to directly operate on the syntax tree, such as raising an
264 s-expression or wrapping it, swallowing or rejecting the following
267 @cindex code snippets
269 @cindex reducing boilerplate
270 We also provide templates for common git commit messages and package
271 definitions in the @file{etc/snippets} directory. These templates can
272 be used with @url{https://joaotavora.github.io/yasnippet/, YASnippet} to
273 expand short trigger strings to interactive text snippets. You may want
274 to add the snippets directory to the @var{yas-snippet-dirs} variable in
278 ;; @r{Assuming the Guix checkout is in ~/src/guix.}
279 (with-eval-after-load 'yasnippet
280 (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets"))
283 The commit message snippets depend on @url{https://magit.vc/, Magit} to
284 display staged files. When editing a commit message type @code{add}
285 followed by @kbd{TAB} to insert a commit message template for adding a
286 package; type @code{update} followed by @kbd{TAB} to insert a template
287 for updating a package; type @code{https} followed by @kbd{TAB} to
288 insert a template for changing the home page URI of a package to HTTPS.
290 The main snippet for @code{scheme-mode} is triggered by typing
291 @code{package...} followed by @kbd{TAB}. This snippet also inserts the
292 trigger string @code{origin...}, which can be expanded further. The
293 @code{origin} snippet in turn may insert other trigger strings ending on
294 @code{...}, which also can be expanded further.
296 @cindex insert or update copyright
297 @cindex @code{M-x guix-copyright}
298 @cindex @code{M-x copyright-update}
299 We additionally provide insertion and automatic update of a copyright in
300 @file{etc/copyright.el}. You may want to set your full name, mail, and
304 (setq user-full-name "Alice Doe")
305 (setq user-mail-address "alice@@mail.org")
306 ;; @r{Assuming the Guix checkout is in ~/src/guix.}
307 (load-file "~/src/guix/etc/copyright.el")
310 To insert a copyright at the current line invoke @code{M-x guix-copyright}.
312 To update a copyright you need to specify a @code{copyright-names-regexp}.
315 (setq copyright-names-regexp
316 (format "%s <%s>" user-full-name user-mail-address))
319 You can check if your copyright is up to date by evaluating @code{M-x
320 copyright-update}. If you want to do it automatically after each buffer
321 save then add @code{(add-hook 'after-save-hook 'copyright-update)} in
324 @node Packaging Guidelines
325 @section Packaging Guidelines
327 @cindex packages, creating
328 The GNU distribution is nascent and may well lack some of your favorite
329 packages. This section describes how you can help make the distribution
332 Free software packages are usually distributed in the form of
333 @dfn{source code tarballs}---typically @file{tar.gz} files that contain
334 all the source files. Adding a package to the distribution means
335 essentially two things: adding a @dfn{recipe} that describes how to
336 build the package, including a list of other packages required to build
337 it, and adding @dfn{package metadata} along with that recipe, such as a
338 description and licensing information.
340 In Guix all this information is embodied in @dfn{package definitions}.
341 Package definitions provide a high-level view of the package. They are
342 written using the syntax of the Scheme programming language; in fact,
343 for each package we define a variable bound to the package definition,
344 and export that variable from a module (@pxref{Package Modules}).
345 However, in-depth Scheme knowledge is @emph{not} a prerequisite for
346 creating packages. For more information on package definitions,
347 @pxref{Defining Packages}.
349 Once a package definition is in place, stored in a file in the Guix
350 source tree, it can be tested using the @command{guix build} command
351 (@pxref{Invoking guix build}). For example, assuming the new package is
352 called @code{gnew}, you may run this command from the Guix build tree
353 (@pxref{Running Guix Before It Is Installed}):
356 ./pre-inst-env guix build gnew --keep-failed
359 Using @code{--keep-failed} makes it easier to debug build failures since
360 it provides access to the failed build tree. Another useful
361 command-line option when debugging is @code{--log-file}, to access the
364 If the package is unknown to the @command{guix} command, it may be that
365 the source file contains a syntax error, or lacks a @code{define-public}
366 clause to export the package variable. To figure it out, you may load
367 the module from Guile to get more information about the actual error:
370 ./pre-inst-env guile -c '(use-modules (gnu packages gnew))'
373 Once your package builds correctly, please send us a patch
374 (@pxref{Submitting Patches}). Well, if you need help, we will be happy to
375 help you too. Once the patch is committed in the Guix repository, the
376 new package automatically gets built on the supported platforms by
377 @url{@value{SUBSTITUTE-URL}, our continuous integration system}.
380 Users can obtain the new package definition simply by running
381 @command{guix pull} (@pxref{Invoking guix pull}). When
382 @code{@value{SUBSTITUTE-SERVER}} is done building the package, installing the
383 package automatically downloads binaries from there
384 (@pxref{Substitutes}). The only place where human intervention is
385 needed is to review and apply the patch.
389 * Software Freedom:: What may go into the distribution.
390 * Package Naming:: What's in a name?
391 * Version Numbers:: When the name is not enough.
392 * Synopses and Descriptions:: Helping users find the right package.
393 * Snippets versus Phases:: Whether to use a snippet, or a build phase.
394 * Python Modules:: A touch of British comedy.
395 * Perl Modules:: Little pearls.
396 * Java Packages:: Coffee break.
397 * Rust Crates:: Beware of oxidation.
398 * Fonts:: Fond of fonts.
401 @node Software Freedom
402 @subsection Software Freedom
404 @c Adapted from http://www.gnu.org/philosophy/philosophy.html.
405 @cindex free software
406 The GNU operating system has been developed so that users can have
407 freedom in their computing. GNU is @dfn{free software}, meaning that
408 users have the @url{https://www.gnu.org/philosophy/free-sw.html,four
409 essential freedoms}: to run the program, to study and change the program
410 in source code form, to redistribute exact copies, and to distribute
411 modified versions. Packages found in the GNU distribution provide only
412 software that conveys these four freedoms.
414 In addition, the GNU distribution follow the
415 @url{https://www.gnu.org/distros/free-system-distribution-guidelines.html,free
416 software distribution guidelines}. Among other things, these guidelines
417 reject non-free firmware, recommendations of non-free software, and
418 discuss ways to deal with trademarks and patents.
420 Some otherwise free upstream package sources contain a small and optional
421 subset that violates the above guidelines, for instance because this subset
422 is itself non-free code. When that happens, the offending items are removed
423 with appropriate patches or code snippets in the @code{origin} form of the
424 package (@pxref{Defining Packages}). This way, @code{guix
425 build --source} returns the ``freed'' source rather than the unmodified
430 @subsection Package Naming
433 A package has actually two names associated with it:
434 First, there is the name of the @emph{Scheme variable}, the one following
435 @code{define-public}. By this name, the package can be made known in the
436 Scheme code, for instance as input to another package. Second, there is
437 the string in the @code{name} field of a package definition. This name
438 is used by package management commands such as
439 @command{guix package} and @command{guix build}.
441 Both are usually the same and correspond to the lowercase conversion of
442 the project name chosen upstream, with underscores replaced with
443 hyphens. For instance, GNUnet is available as @code{gnunet}, and
444 SDL_net as @code{sdl-net}.
446 We do not add @code{lib} prefixes for library packages, unless these are
447 already part of the official project name. But @pxref{Python
448 Modules} and @ref{Perl Modules} for special rules concerning modules for
449 the Python and Perl languages.
451 Font package names are handled differently, @pxref{Fonts}.
454 @node Version Numbers
455 @subsection Version Numbers
457 @cindex package version
458 We usually package only the latest version of a given free software
459 project. But sometimes, for instance for incompatible library versions,
460 two (or more) versions of the same package are needed. These require
461 different Scheme variable names. We use the name as defined
462 in @ref{Package Naming}
463 for the most recent version; previous versions use the same name, suffixed
464 by @code{-} and the smallest prefix of the version number that may
465 distinguish the two versions.
467 The name inside the package definition is the same for all versions of a
468 package and does not contain any version number.
470 For instance, the versions 2.24.20 and 3.9.12 of GTK+ may be packaged as follows:
478 (define-public gtk+-2
484 If we also wanted GTK+ 3.8.2, this would be packaged as
486 (define-public gtk+-3.8
493 @c See <https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00425.html>,
494 @c for a discussion of what follows.
495 @cindex version number, for VCS snapshots
496 Occasionally, we package snapshots of upstream's version control system
497 (VCS) instead of formal releases. This should remain exceptional,
498 because it is up to upstream developers to clarify what the stable
499 release is. Yet, it is sometimes necessary. So, what should we put in
500 the @code{version} field?
502 Clearly, we need to make the commit identifier of the VCS snapshot
503 visible in the version string, but we also need to make sure that the
504 version string is monotonically increasing so that @command{guix package
505 --upgrade} can determine which version is newer. Since commit
506 identifiers, notably with Git, are not monotonically increasing, we add
507 a revision number that we increase each time we upgrade to a newer
508 snapshot. The resulting version string looks like this:
513 | | `-- upstream commit ID
515 | `--- Guix package revision
517 latest upstream version
520 It is a good idea to strip commit identifiers in the @code{version}
521 field to, say, 7 digits. It avoids an aesthetic annoyance (assuming
522 aesthetics have a role to play here) as well as problems related to OS
523 limits such as the maximum shebang length (127 bytes for the Linux
524 kernel). It is best to use the full commit identifiers in
525 @code{origin}s, though, to avoid ambiguities. A typical package
526 definition may look like this:
530 (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
531 (revision "1")) ;Guix package revision
533 (version (git-version "0.9" revision commit))
537 (url "git://example.org/my-package.git")
539 (sha256 (base32 "1mbikn@dots{}"))
540 (file-name (git-file-name name version))))
545 @node Synopses and Descriptions
546 @subsection Synopses and Descriptions
548 @cindex package description
549 @cindex package synopsis
550 As we have seen before, each package in GNU@tie{}Guix includes a
551 synopsis and a description (@pxref{Defining Packages}). Synopses and
552 descriptions are important: They are what @command{guix package
553 --search} searches, and a crucial piece of information to help users
554 determine whether a given package suits their needs. Consequently,
555 packagers should pay attention to what goes into them.
557 Synopses must start with a capital letter and must not end with a
558 period. They must not start with ``a'' or ``the'', which usually does
559 not bring anything; for instance, prefer ``File-frobbing tool'' over ``A
560 tool that frobs files''. The synopsis should say what the package
561 is---e.g., ``Core GNU utilities (file, text, shell)''---or what it is
562 used for---e.g., the synopsis for GNU@tie{}grep is ``Print lines
563 matching a pattern''.
565 Keep in mind that the synopsis must be meaningful for a very wide
566 audience. For example, ``Manipulate alignments in the SAM format''
567 might make sense for a seasoned bioinformatics researcher, but might be
568 fairly unhelpful or even misleading to a non-specialized audience. It
569 is a good idea to come up with a synopsis that gives an idea of the
570 application domain of the package. In this example, this might give
571 something like ``Manipulate nucleotide sequence alignments'', which
572 hopefully gives the user a better idea of whether this is what they are
575 Descriptions should take between five and ten lines. Use full
576 sentences, and avoid using acronyms without first introducing them.
577 Please avoid marketing phrases such as ``world-leading'',
578 ``industrial-strength'', and ``next-generation'', and avoid superlatives
579 like ``the most advanced''---they are not helpful to users looking for a
580 package and may even sound suspicious. Instead, try to be factual,
581 mentioning use cases and features.
583 @cindex Texinfo markup, in package descriptions
584 Descriptions can include Texinfo markup, which is useful to introduce
585 ornaments such as @code{@@code} or @code{@@dfn}, bullet lists, or
586 hyperlinks (@pxref{Overview,,, texinfo, GNU Texinfo}). However you
587 should be careful when using some characters for example @samp{@@} and
588 curly braces which are the basic special characters in Texinfo
589 (@pxref{Special Characters,,, texinfo, GNU Texinfo}). User interfaces
590 such as @command{guix package --show} take care of rendering it
593 Synopses and descriptions are translated by volunteers
594 @uref{https://translationproject.org/domain/guix-packages.html, at the
595 Translation Project} so that as many users as possible can read them in
596 their native language. User interfaces search them and display them in
597 the language specified by the current locale.
599 To allow @command{xgettext} to extract them as translatable strings,
600 synopses and descriptions @emph{must be literal strings}. This means
601 that you cannot use @code{string-append} or @code{format} to construct
607 (synopsis "This is translatable")
608 (description (string-append "This is " "*not*" " translatable.")))
611 Translation is a lot of work so, as a packager, please pay even more
612 attention to your synopses and descriptions as every change may entail
613 additional work for translators. In order to help them, it is possible
614 to make recommendations or instructions visible to them by inserting
615 special comments like this (@pxref{xgettext Invocation,,, gettext, GNU
619 ;; TRANSLATORS: "X11 resize-and-rotate" should not be translated.
620 (description "ARandR is designed to provide a simple visual front end
621 for the X11 resize-and-rotate (RandR) extension. @dots{}")
624 @node Snippets versus Phases
625 @subsection Snippets versus Phases
627 @cindex snippets, when to use
628 The boundary between using an origin snippet versus a build phase to
629 modify the sources of a package can be elusive. Origin snippets are
630 typically used to remove unwanted files such as bundled libraries,
631 nonfree sources, or to apply simple substitutions. The source derived
632 from an origin should produce a source that can be used to build the
633 package on any system that the upstream package supports (i.e., act as
634 the corresponding source). In particular, origin snippets must not
635 embed store items in the sources; such patching should rather be done
636 using build phases. Refer to the @code{origin} record documentation for
637 more information (@pxref{origin Reference}).
640 @subsection Python Modules
643 We currently package Python 2 and Python 3, under the Scheme variable names
644 @code{python-2} and @code{python} as explained in @ref{Version Numbers}.
645 To avoid confusion and naming clashes with other programming languages, it
646 seems desirable that the name of a package for a Python module contains
647 the word @code{python}.
649 Some modules are compatible with only one version of Python, others with
650 both. If the package Foo is compiled with Python 3, we name it
651 @code{python-foo}. If it is compiled with Python 2, we name it
652 @code{python2-foo}. Packages should be added when they are necessary;
653 we don't add Python 2 variants of the package unless we are going to use
656 If a project already contains the word @code{python}, we drop this;
657 for instance, the module python-dateutil is packaged under the names
658 @code{python-dateutil} and @code{python2-dateutil}. If the project name
659 starts with @code{py} (e.g.@: @code{pytz}), we keep it and prefix it as
662 @subsubsection Specifying Dependencies
663 @cindex inputs, for Python packages
665 Dependency information for Python packages is usually available in the
666 package source tree, with varying degrees of accuracy: in the
667 @file{setup.py} file, in @file{requirements.txt}, or in @file{tox.ini}.
669 Your mission, when writing a recipe for a Python package, is to map
670 these dependencies to the appropriate type of ``input'' (@pxref{package
671 Reference, inputs}). Although the @code{pypi} importer normally does a
672 good job (@pxref{Invoking guix import}), you may want to check the
673 following check list to determine which dependency goes where.
678 We currently package Python 2 with @code{setuptools} and @code{pip}
679 installed like Python 3.4 has per default. Thus you don't need to
680 specify either of these as an input. @command{guix lint} will warn you
684 Python dependencies required at run time go into
685 @code{propagated-inputs}. They are typically defined with the
686 @code{install_requires} keyword in @file{setup.py}, or in the
687 @file{requirements.txt} file.
690 Python packages required only at build time---e.g., those listed with
691 the @code{setup_requires} keyword in @file{setup.py}---or only for
692 testing---e.g., those in @code{tests_require}---go into
693 @code{native-inputs}. The rationale is that (1) they do not need to be
694 propagated because they are not needed at run time, and (2) in a
695 cross-compilation context, it's the ``native'' input that we'd want.
697 Examples are the @code{pytest}, @code{mock}, and @code{nose} test
698 frameworks. Of course if any of these packages is also required at
699 run-time, it needs to go to @code{propagated-inputs}.
702 Anything that does not fall in the previous categories goes to
703 @code{inputs}, for example programs or C libraries required for building
704 Python packages containing C extensions.
707 If a Python package has optional dependencies (@code{extras_require}),
708 it is up to you to decide whether to add them or not, based on their
709 usefulness/overhead ratio (@pxref{Submitting Patches, @command{guix
716 @subsection Perl Modules
719 Perl programs standing for themselves are named as any other package,
720 using the lowercase upstream name.
721 For Perl packages containing a single class, we use the lowercase class name,
722 replace all occurrences of @code{::} by dashes and prepend the prefix
724 So the class @code{XML::Parser} becomes @code{perl-xml-parser}.
725 Modules containing several classes keep their lowercase upstream name and
726 are also prepended by @code{perl-}. Such modules tend to have the word
727 @code{perl} somewhere in their name, which gets dropped in favor of the
728 prefix. For instance, @code{libwww-perl} becomes @code{perl-libwww}.
732 @subsection Java Packages
735 Java programs standing for themselves are named as any other package,
736 using the lowercase upstream name.
738 To avoid confusion and naming clashes with other programming languages,
739 it is desirable that the name of a package for a Java package is
740 prefixed with @code{java-}. If a project already contains the word
741 @code{java}, we drop this; for instance, the package @code{ngsjava} is
742 packaged under the name @code{java-ngs}.
744 For Java packages containing a single class or a small class hierarchy,
745 we use the lowercase class name, replace all occurrences of @code{.} by
746 dashes and prepend the prefix @code{java-}. So the class
747 @code{apache.commons.cli} becomes package
748 @code{java-apache-commons-cli}.
752 @subsection Rust Crates
755 Rust programs standing for themselves are named as any other package, using the
756 lowercase upstream name.
758 To prevent namespace collisions we prefix all other Rust packages with the
759 @code{rust-} prefix. The name should be changed to lowercase as appropriate and
760 dashes should remain in place.
762 In the rust ecosystem it is common for multiple incompatible versions of a
763 package to be used at any given time, so all packages should have a versioned
764 suffix. If a package has passed version 1.0.0 then just the major version
765 number is sufficient (e.g.@: @code{rust-clap-2}), otherwise the version suffix
766 should contain both the major and minor version (e.g.@: @code{rust-rand-0.6}).
768 Because of the difficulty in reusing rust packages as pre-compiled inputs for
769 other packages the Cargo build system (@pxref{Build Systems,
770 @code{cargo-build-system}}) presents the @code{#:cargo-inputs} and
771 @code{cargo-development-inputs} keywords as build system arguments. It would be
772 helpful to think of these as similar to @code{propagated-inputs} and
773 @code{native-inputs}. Rust @code{dependencies} and @code{build-dependencies}
774 should go in @code{#:cargo-inputs}, and @code{dev-dependencies} should go in
775 @code{#:cargo-development-inputs}. If a Rust package links to other libraries
776 then the standard placement in @code{inputs} and the like should be used.
778 Care should be taken to ensure the correct version of dependencies are used; to
779 this end we try to refrain from skipping the tests or using @code{#:skip-build?}
780 when possible. Of course this is not always possible, as the package may be
781 developed for a different Operating System, depend on features from the Nightly
782 Rust compiler, or the test suite may have atrophied since it was released.
789 For fonts that are in general not installed by a user for typesetting
790 purposes, or that are distributed as part of a larger software package,
791 we rely on the general packaging rules for software; for instance, this
792 applies to the fonts delivered as part of the X.Org system or fonts that
793 are part of TeX Live.
795 To make it easier for a user to search for fonts, names for other packages
796 containing only fonts are constructed as follows, independently of the
797 upstream package name.
799 The name of a package containing only one font family starts with
800 @code{font-}; it is followed by the foundry name and a dash @code{-}
801 if the foundry is known, and the font family name, in which spaces are
802 replaced by dashes (and as usual, all upper case letters are transformed
804 For example, the Gentium font family by SIL is packaged under the name
805 @code{font-sil-gentium}.
807 For a package containing several font families, the name of the collection
808 is used in the place of the font family name.
809 For instance, the Liberation fonts consist of three families,
810 Liberation Sans, Liberation Serif and Liberation Mono.
811 These could be packaged separately under the names
812 @code{font-liberation-sans} and so on; but as they are distributed together
813 under a common name, we prefer to package them together as
814 @code{font-liberation}.
816 In the case where several formats of the same font family or font collection
817 are packaged separately, a short form of the format, prepended by a dash,
818 is added to the package name. We use @code{-ttf} for TrueType fonts,
819 @code{-otf} for OpenType fonts and @code{-type1} for PostScript Type 1
824 @section Coding Style
826 In general our code follows the GNU Coding Standards (@pxref{Top,,,
827 standards, GNU Coding Standards}). However, they do not say much about
828 Scheme, so here are some additional rules.
831 * Programming Paradigm:: How to compose your elements.
832 * Modules:: Where to store your code?
833 * Data Types and Pattern Matching:: Implementing data structures.
834 * Formatting Code:: Writing conventions.
837 @node Programming Paradigm
838 @subsection Programming Paradigm
840 Scheme code in Guix is written in a purely functional style. One
841 exception is code that involves input/output, and procedures that
842 implement low-level concepts, such as the @code{memoize} procedure.
847 Guile modules that are meant to be used on the builder side must live in
848 the @code{(guix build @dots{})} name space. They must not refer to
849 other Guix or GNU modules. However, it is OK for a ``host-side'' module
850 to use a build-side module.
852 Modules that deal with the broader GNU system should be in the
853 @code{(gnu @dots{})} name space rather than @code{(guix @dots{})}.
855 @node Data Types and Pattern Matching
856 @subsection Data Types and Pattern Matching
858 The tendency in classical Lisp is to use lists to represent everything,
859 and then to browse them ``by hand'' using @code{car}, @code{cdr},
860 @code{cadr}, and co. There are several problems with that style,
861 notably the fact that it is hard to read, error-prone, and a hindrance
862 to proper type error reports.
864 Guix code should define appropriate data types (for instance, using
865 @code{define-record-type*}) rather than abuse lists. In addition, it
866 should use pattern matching, via Guile’s @code{(ice-9 match)} module,
867 especially when matching lists.
869 @node Formatting Code
870 @subsection Formatting Code
872 @cindex formatting code
874 When writing Scheme code, we follow common wisdom among Scheme
875 programmers. In general, we follow the
876 @url{https://mumble.net/~campbell/scheme/style.txt, Riastradh's Lisp
877 Style Rules}. This document happens to describe the conventions mostly
878 used in Guile’s code too. It is very thoughtful and well written, so
881 Some special forms introduced in Guix, such as the @code{substitute*}
882 macro, have special indentation rules. These are defined in the
883 @file{.dir-locals.el} file, which Emacs automatically uses. Also note
884 that Emacs-Guix provides @code{guix-devel-mode} mode that indents and
885 highlights Guix code properly (@pxref{Development,,, emacs-guix, The
886 Emacs-Guix Reference Manual}).
888 @cindex indentation, of code
889 @cindex formatting, of code
890 If you do not use Emacs, please make sure to let your editor knows these
891 rules. To automatically indent a package definition, you can also run:
894 ./etc/indent-code.el gnu/packages/@var{file}.scm @var{package}
898 This automatically indents the definition of @var{package} in
899 @file{gnu/packages/@var{file}.scm} by running Emacs in batch mode. To
900 indent a whole file, omit the second argument:
903 ./etc/indent-code.el gnu/services/@var{file}.scm
906 @cindex Vim, Scheme code editing
907 If you are editing code with Vim, we recommend that you run @code{:set
908 autoindent} so that your code is automatically indented as you type.
910 @uref{https://www.vim.org/scripts/script.php?script_id=3998,
911 @code{paredit.vim}} may help you deal with all these parentheses.
913 We require all top-level procedures to carry a docstring. This
914 requirement can be relaxed for simple private procedures in the
915 @code{(guix build @dots{})} name space, though.
917 Procedures should not have more than four positional parameters. Use
918 keyword parameters for procedures that take more than four parameters.
921 @node Submitting Patches
922 @section Submitting Patches
924 Development is done using the Git distributed version control system.
925 Thus, access to the repository is not strictly necessary. We welcome
926 contributions in the form of patches as produced by @code{git
927 format-patch} sent to the @email{guix-patches@@gnu.org} mailing list.
928 Seasoned Guix developers may also want to look at the section on commit
929 access (@pxref{Commit Access}).
931 This mailing list is backed by a Debbugs instance, which allows us to
932 keep track of submissions (@pxref{Tracking Bugs and Patches}). Each
933 message sent to that mailing list gets a new tracking number assigned;
934 people can then follow up on the submission by sending email to
935 @code{@var{NNN}@@debbugs.gnu.org}, where @var{NNN} is the tracking
936 number (@pxref{Sending a Patch Series}).
938 Please write commit logs in the ChangeLog format (@pxref{Change Logs,,,
939 standards, GNU Coding Standards}); you can check the commit history for
942 Before submitting a patch that adds or modifies a package definition,
943 please run through this check list:
947 If the authors of the packaged software provide a cryptographic
948 signature for the release tarball, make an effort to verify the
949 authenticity of the archive. For a detached GPG signature file this
950 would be done with the @code{gpg --verify} command.
953 Take some time to provide an adequate synopsis and description for the
954 package. @xref{Synopses and Descriptions}, for some guidelines.
957 Run @code{guix lint @var{package}}, where @var{package} is the
958 name of the new or modified package, and fix any errors it reports
959 (@pxref{Invoking guix lint}).
962 Make sure the package builds on your platform, using @code{guix build
966 We recommend you also try building the package on other supported
967 platforms. As you may not have access to actual hardware platforms, we
968 recommend using the @code{qemu-binfmt-service-type} to emulate them. In
969 order to enable it, add the following service to the list of services in
970 your @code{operating-system} configuration:
973 (service qemu-binfmt-service-type
974 (qemu-binfmt-configuration
975 (platforms (lookup-qemu-platforms "arm" "aarch64"))
979 Then reconfigure your system.
981 You can then build packages for different platforms by specifying the
982 @code{--system} option. For example, to build the "hello" package for
983 the armhf, aarch64, or mips64 architectures, you would run the following
984 commands, respectively:
986 guix build --system=armhf-linux --rounds=2 hello
987 guix build --system=aarch64-linux --rounds=2 hello
992 Make sure the package does not use bundled copies of software already
993 available as separate packages.
995 Sometimes, packages include copies of the source code of their
996 dependencies as a convenience for users. However, as a distribution, we
997 want to make sure that such packages end up using the copy we already
998 have in the distribution, if there is one. This improves resource usage
999 (the dependency is built and stored only once), and allows the
1000 distribution to make transverse changes such as applying security
1001 updates for a given software package in a single place and have them
1002 affect the whole system---something that bundled copies prevent.
1005 Take a look at the profile reported by @command{guix size}
1006 (@pxref{Invoking guix size}). This will allow you to notice references
1007 to other packages unwillingly retained. It may also help determine
1008 whether to split the package (@pxref{Packages with Multiple Outputs}),
1009 and which optional dependencies should be used. In particular, avoid adding
1010 @code{texlive} as a dependency: because of its extreme size, use
1011 @code{texlive-tiny} or @code{texlive-union} instead.
1014 For important changes, check that dependent package (if applicable) are
1015 not affected by the change; @code{guix refresh --list-dependent
1016 @var{package}} will help you do that (@pxref{Invoking guix refresh}).
1018 @c See <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>.
1019 @cindex branching strategy
1020 @cindex rebuild scheduling strategy
1021 Depending on the number of dependent packages and thus the amount of
1022 rebuilding induced, commits go to different branches, along these lines:
1025 @item 300 dependent packages or less
1026 @code{master} branch (non-disruptive changes).
1028 @item between 300 and 1,800 dependent packages
1029 @code{staging} branch (non-disruptive changes). This branch is intended
1030 to be merged in @code{master} every 6 weeks or so. Topical changes
1031 (e.g., an update of the GNOME stack) can instead go to a specific branch
1032 (say, @code{gnome-updates}).
1034 @item more than 1,800 dependent packages
1035 @code{core-updates} branch (may include major and potentially disruptive
1036 changes). This branch is intended to be merged in @code{master} every
1040 All these branches are @uref{@value{SUBSTITUTE-URL},
1041 tracked by our build farm} and merged into @code{master} once
1042 everything has been successfully built. This allows us to fix issues
1043 before they hit users, and to reduce the window during which pre-built
1044 binaries are not available.
1046 Generally, branches other than @code{master} are considered
1047 @emph{frozen} if there has been a recent evaluation, or there is a
1048 corresponding @code{-next} branch. Please ask on the mailing list or
1049 IRC if unsure where to place a patch.
1050 @c TODO: It would be good with badges on the website that tracks these
1051 @c branches. Or maybe even a status page.
1054 @cindex determinism, of build processes
1055 @cindex reproducible builds, checking
1056 Check whether the package's build process is deterministic. This
1057 typically means checking whether an independent build of the package
1058 yields the exact same result that you obtained, bit for bit.
1060 A simple way to do that is by building the same package several times in
1061 a row on your machine (@pxref{Invoking guix build}):
1064 guix build --rounds=2 my-package
1067 This is enough to catch a class of common non-determinism issues, such
1068 as timestamps or randomly-generated output in the build result.
1070 Another option is to use @command{guix challenge} (@pxref{Invoking guix
1071 challenge}). You may run it once the package has been committed and
1072 built by @code{@value{SUBSTITUTE-SERVER}} to check whether it obtains the same
1073 result as you did. Better yet: Find another machine that can build it
1074 and run @command{guix publish}. Since the remote build machine is
1075 likely different from yours, this can catch non-determinism issues
1076 related to the hardware---e.g., use of different instruction set
1077 extensions---or to the operating system kernel---e.g., reliance on
1078 @code{uname} or @file{/proc} files.
1081 When writing documentation, please use gender-neutral wording when
1082 referring to people, such as
1083 @uref{https://en.wikipedia.org/wiki/Singular_they, singular
1084 ``they''@comma{} ``their''@comma{} ``them''}, and so forth.
1087 Verify that your patch contains only one set of related changes.
1088 Bundling unrelated changes together makes reviewing harder and slower.
1090 Examples of unrelated changes include the addition of several packages,
1091 or a package update along with fixes to that package.
1094 Please follow our code formatting rules, possibly running the
1095 @command{etc/indent-code.el} script to do that automatically for you
1096 (@pxref{Formatting Code}).
1099 When possible, use mirrors in the source URL (@pxref{Invoking guix download}).
1100 Use reliable URLs, not generated ones. For instance, GitHub archives are not
1101 necessarily identical from one generation to the next, so in this case it's
1102 often better to clone the repository. Don't use the @command{name} field in
1103 the URL: it is not very useful and if the name changes, the URL will probably
1107 Check if Guix builds (@pxref{Building from Git}) and address the
1108 warnings, especially those about use of undefined symbols.
1111 Make sure your changes do not break Guix and simulate a @code{guix pull} with:
1113 guix pull --url=/path/to/your/checkout --profile=/tmp/guix.master
1118 When posting a patch to the mailing list, use @samp{[PATCH] @dots{}} as
1119 a subject, if your patch is to be applied on a branch other than
1120 @code{master}, say @code{core-updates}, specify it in the subject like
1121 @samp{[PATCH core-updates] @dots{}}. You may use your email client or
1122 the @command{git send-email} command (@pxref{Sending a Patch Series}).
1123 We prefer to get patches in plain text messages, either inline or as
1124 MIME attachments. You are advised to pay attention if your email client
1125 changes anything like line breaks or indentation which could potentially
1128 When a bug is resolved, please close the thread by sending an email to
1129 @email{@var{NNN}-done@@debbugs.gnu.org}.
1131 @unnumberedsubsec Sending a Patch Series
1132 @anchor{Sending a Patch Series}
1133 @cindex patch series
1134 @cindex @code{git send-email}
1135 @cindex @code{git-send-email}
1137 When sending a patch series (e.g., using @code{git send-email}), please
1138 first send one message to @email{guix-patches@@gnu.org}, and then send
1139 subsequent patches to @email{@var{NNN}@@debbugs.gnu.org} to make sure
1140 they are kept together. See
1141 @uref{https://debbugs.gnu.org/Advanced.html, the Debbugs documentation}
1142 for more information. You can install @command{git send-email} with
1143 @command{guix install git:send-email}.
1144 @c Debbugs bug: https://debbugs.gnu.org/db/15/15361.html
1146 @node Tracking Bugs and Patches
1147 @section Tracking Bugs and Patches
1149 @cindex bug reports, tracking
1150 @cindex patch submissions, tracking
1151 @cindex issue tracking
1152 @cindex Debbugs, issue tracking system
1153 Bug reports and patch submissions are currently tracked using the
1154 Debbugs instance at @uref{https://bugs.gnu.org}. Bug reports are filed
1155 against the @code{guix} ``package'' (in Debbugs parlance), by sending
1156 email to @email{bug-guix@@gnu.org}, while patch submissions are filed
1157 against the @code{guix-patches} package by sending email to
1158 @email{guix-patches@@gnu.org} (@pxref{Submitting Patches}).
1160 A web interface (actually @emph{two} web interfaces!) are available to
1165 @url{https://issues.guix.gnu.org} provides a pleasant
1166 interface@footnote{The web interface at
1167 @url{https://issues.guix.gnu.org} is powered by Mumi, a nice piece of
1168 software written in Guile, and you can help! See
1169 @url{https://git.elephly.net/gitweb.cgi?p=software/mumi.git}.} to browse
1170 bug reports and patches, and to participate in discussions;
1172 @url{https://bugs.gnu.org/guix} lists bug reports;
1174 @url{https://bugs.gnu.org/guix-patches} lists patch submissions.
1177 To view discussions related to issue number @var{n}, go to
1178 @indicateurl{https://issues.guix.gnu.org/@var{n}} or
1179 @indicateurl{https://bugs.gnu.org/@var{n}}.
1181 If you use Emacs, you may find it more convenient to interact with
1182 issues using @file{debbugs.el}, which you can install with:
1185 guix install emacs-debbugs
1188 For example, to list all open issues on @code{guix-patches}, hit:
1191 @kbd{C-u} @kbd{M-x} debbugs-gnu @kbd{RET} @kbd{RET} guix-patches @kbd{RET} n y
1194 @xref{Top,,, debbugs-ug, Debbugs User Guide}, for more information on
1198 @section Commit Access
1200 @cindex commit access, for developers
1201 For frequent contributors, having write access to the repository is
1202 convenient. When you deem it necessary, consider applying for commit
1203 access by following these steps:
1207 Find three committers who would vouch for you. You can view the list of
1209 @url{https://savannah.gnu.org/project/memberlist.php?group=guix}. Each
1210 of them should email a statement to @email{guix-maintainers@@gnu.org} (a
1211 private alias for the collective of maintainers), signed with their
1214 Committers are expected to have had some interactions with you as a
1215 contributor and to be able to judge whether you are sufficiently
1216 familiar with the project's practices. It is @emph{not} a judgment on
1217 the value of your work, so a refusal should rather be interpreted as
1218 ``let's try again later''.
1221 Send @email{guix-maintainers@@gnu.org} a message stating your intent,
1222 listing the three committers who support your application, signed with
1223 the OpenPGP key you will use to sign commits, and giving its fingerprint
1224 (see below). See @uref{https://emailselfdefense.fsf.org/en/}, for an
1225 introduction to public-key cryptography with GnuPG.
1227 @c See <https://sha-mbles.github.io/>.
1228 Set up GnuPG such that it never uses the SHA1 hash algorithm for digital
1229 signatures, which is known to be unsafe since 2019, for instance by
1230 adding the following line to @file{~/.gnupg/gpg.conf} (@pxref{GPG
1231 Esoteric Options,,, gnupg, The GNU Privacy Guard Manual}):
1238 Maintainers ultimately decide whether to grant you commit access,
1239 usually following your referrals' recommendation.
1242 @cindex OpenPGP, signed commits
1243 If and once you've been given access, please send a message to
1244 @email{guix-devel@@gnu.org} to say so, again signed with the OpenPGP key
1245 you will use to sign commits (do that before pushing your first commit).
1246 That way, everyone can notice and ensure you control that OpenPGP key.
1248 @quotation Important
1249 Before you can push for the first time, maintainers must:
1253 add your OpenPGP key to the @code{keyring} branch;
1255 add your OpenPGP fingerprint to the @file{.guix-authorizations} file of
1256 the branch(es) you will commit to.
1261 Make sure to read the rest of this section and... profit!
1265 Maintainers are happy to give commit access to people who have been
1266 contributing for some time and have a track record---don't be shy and
1267 don't underestimate your work!
1269 However, note that the project is working towards a more automated patch
1270 review and merging system, which, as a consequence, may lead us to have
1271 fewer people with commit access to the main repository. Stay tuned!
1274 If you get commit access, please make sure to follow
1275 the policy below (discussions of the policy can take place on
1276 @email{guix-devel@@gnu.org}).
1278 Non-trivial patches should always be posted to
1279 @email{guix-patches@@gnu.org} (trivial patches include fixing typos,
1280 etc.). This mailing list fills the patch-tracking database
1281 (@pxref{Tracking Bugs and Patches}).
1283 For patches that just add a new package, and a simple one, it's OK to
1284 commit, if you're confident (which means you successfully built it in a
1285 chroot setup, and have done a reasonable copyright and license
1286 auditing). Likewise for package upgrades, except upgrades that trigger
1287 a lot of rebuilds (for example, upgrading GnuTLS or GLib). We have a
1288 mailing list for commit notifications (@email{guix-commits@@gnu.org}),
1289 so people can notice. Before pushing your changes, make sure to run
1290 @code{git pull --rebase}.
1292 All commits that are pushed to the central repository on Savannah must
1293 be signed with an OpenPGP key, and the public key should be uploaded to
1294 your user account on Savannah and to public key servers, such as
1295 @code{keys.openpgp.org}. To configure Git to automatically sign
1299 git config commit.gpgsign true
1300 git config user.signingkey CABBA6EA1DC0FF33
1303 You can prevent yourself from accidentally pushing unsigned commits to
1304 Savannah by using the pre-push Git hook called located at
1305 @file{etc/git/pre-push}:
1308 cp etc/git/pre-push .git/hooks/pre-push
1311 When pushing a commit on behalf of somebody else, please add a
1312 @code{Signed-off-by} line at the end of the commit log message---e.g.,
1313 with @command{git am --signoff}. This improves tracking of who did
1316 When adding channel news entries (@pxref{Channels, Writing Channel
1317 News}), make sure they are well-formed by running the following command
1318 right before pushing:
1321 make check-channel-news
1324 For anything else, please post to @email{guix-patches@@gnu.org} and
1325 leave time for a review, without committing anything (@pxref{Submitting
1326 Patches}). If you didn’t receive any reply after two weeks, and if
1327 you're confident, it's OK to commit.
1329 That last part is subject to being adjusted, allowing individuals to commit
1330 directly on non-controversial changes on parts they’re familiar with.
1332 One last thing: the project keeps moving forward because committers not
1333 only push their own awesome changes, but also offer some of their time
1334 @emph{reviewing} and pushing other people's changes. As a committer,
1335 you're welcome to use your expertise and commit rights to help other
1338 @node Updating the Guix Package
1339 @section Updating the Guix Package
1341 @cindex update-guix-package, updating the guix package
1342 It is sometimes desirable to update the @code{guix} package itself (the
1343 package defined in @code{(gnu packages package-management)}), for
1344 example to make new daemon features available for use by the
1345 @code{guix-service-type} service type. In order to simplify this task,
1346 the following command can be used:
1349 make update-guix-package
1352 The @code{update-guix-package} make target will use the last known
1353 @emph{commit} corresponding to @code{HEAD} in your Guix checkout,
1354 compute the hash of the Guix sources corresponding to that commit and
1355 update the @code{commit}, @code{revision} and hash of the @code{guix}
1358 To validate that the updated @code{guix} package hashes are correct and
1359 that it can be built successfully, the following command can be run from
1360 the directory of your Guix checkout:
1363 ./pre-inst-env guix build guix
1366 To guard against accidentally updating the @code{guix} package to a
1367 commit that others can't refer to, a check is made that the commit used
1368 has already been pushed to the Savannah-hosted Guix git repository.
1370 This check can be disabled, @emph{at your own peril}, by setting the
1371 @code{GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT} environment variable. When
1372 this variable is set, the updated package source is also added to the
1373 store. This is used as part of the release process of Guix.