doc: Move "Packaging Guidelines" under "Contributing".

* doc/guix.texi (Packaging Guidelines): Move to... * doc/contributing.texi (Packaging Guidelines): ... here. Turn into a section. Adjust references to "Contributing".
2019-01-21 11:31:54 +01:00 · 2019-01-21 11:31:54 +01:00 · afe7408e19
parent 83db020506
commit afe7408e19
2 changed files with 450 additions and 462 deletions
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@ -23,6 +23,7 @@ choice.
 * Building from Git::           The latest and greatest.
 * Running Guix Before It Is Installed::  Hacker tricks.
 * The Perfect Setup::           The right tools.
 * Packaging Guidelines::        Growing the distribution.
 * Coding Style::                Hygiene of the contributor.
 * Submitting Patches::          Share your work.
@end menu
@ -223,6 +224,455 @@ trigger string @code{origin...}, which can be expanded further.  The
@code{...}, which also can be expanded further.
@node Packaging Guidelines
@section Packaging Guidelines
@cindex packages, creating
 The GNU distribution is nascent and may well lack some of your favorite
 packages.  This section describes how you can help make the distribution
 grow.
 Free software packages are usually distributed in the form of
@dfn{source code tarballs}---typically @file{tar.gz} files that contain
 all the source files.  Adding a package to the distribution means
 essentially two things: adding a @dfn{recipe} that describes how to
 build the package, including a list of other packages required to build
 it, and adding @dfn{package metadata} along with that recipe, such as a
 description and licensing information.
 In Guix all this information is embodied in @dfn{package definitions}.
 Package definitions provide a high-level view of the package.  They are
 written using the syntax of the Scheme programming language; in fact,
 for each package we define a variable bound to the package definition,
 and export that variable from a module (@pxref{Package Modules}).
 However, in-depth Scheme knowledge is @emph{not} a prerequisite for
 creating packages.  For more information on package definitions,
@pxref{Defining Packages}.
 Once a package definition is in place, stored in a file in the Guix
 source tree, it can be tested using the @command{guix build} command
 (@pxref{Invoking guix build}).  For example, assuming the new package is
 called @code{gnew}, you may run this command from the Guix build tree
 (@pxref{Running Guix Before It Is Installed}):
@example
 ./pre-inst-env guix build gnew --keep-failed
@end example
 Using @code{--keep-failed} makes it easier to debug build failures since
 it provides access to the failed build tree.  Another useful
 command-line option when debugging is @code{--log-file}, to access the
 build log.
 If the package is unknown to the @command{guix} command, it may be that
 the source file contains a syntax error, or lacks a @code{define-public}
 clause to export the package variable.  To figure it out, you may load
 the module from Guile to get more information about the actual error:
@example
 ./pre-inst-env guile -c '(use-modules (gnu packages gnew))'
@end example
 Once your package builds correctly, please send us a patch
 (@pxref{Submitting Patches}).  Well, if you need help, we will be happy to
 help you too.  Once the patch is committed in the Guix repository, the
 new package automatically gets built on the supported platforms by
@url{http://hydra.gnu.org/jobset/gnu/master, our continuous integration
 system}.
@cindex substituter
 Users can obtain the new package definition simply by running
@command{guix pull} (@pxref{Invoking guix pull}).  When
@code{@value{SUBSTITUTE-SERVER}} is done building the package, installing the
 package automatically downloads binaries from there
 (@pxref{Substitutes}).  The only place where human intervention is
 needed is to review and apply the patch.
@menu
 * Software Freedom::            What may go into the distribution.
 * Package Naming::              What's in a name?
 * Version Numbers::             When the name is not enough.
 * Synopses and Descriptions::   Helping users find the right package.
 * Python Modules::              A touch of British comedy.
 * Perl Modules::                Little pearls.
 * Java Packages::               Coffee break.
 * Fonts::                       Fond of fonts.
@end menu
@node Software Freedom
@subsection Software Freedom
@c Adapted from http://www.gnu.org/philosophy/philosophy.html.
@cindex free software
 The GNU operating system has been developed so that users can have
 freedom in their computing.  GNU is @dfn{free software}, meaning that
 users have the @url{http://www.gnu.org/philosophy/free-sw.html,four
 essential freedoms}: to run the program, to study and change the program
 in source code form, to redistribute exact copies, and to distribute
 modified versions.  Packages found in the GNU distribution provide only
 software that conveys these four freedoms.
 In addition, the GNU distribution follow the
@url{http://www.gnu.org/distros/free-system-distribution-guidelines.html,free
 software distribution guidelines}.  Among other things, these guidelines
 reject non-free firmware, recommendations of non-free software, and
 discuss ways to deal with trademarks and patents.
 Some otherwise free upstream package sources contain a small and optional
 subset that violates the above guidelines, for instance because this subset
 is itself non-free code.  When that happens, the offending items are removed
 with appropriate patches or code snippets in the @code{origin} form of the
 package (@pxref{Defining Packages}).  This way, @code{guix
 build --source} returns the ``freed'' source rather than the unmodified
 upstream source.
@node Package Naming
@subsection Package Naming
@cindex package name
 A package has actually two names associated with it:
 First, there is the name of the @emph{Scheme variable}, the one following
@code{define-public}.  By this name, the package can be made known in the
 Scheme code, for instance as input to another package.  Second, there is
 the string in the @code{name} field of a package definition.  This name
 is used by package management commands such as
@command{guix package} and @command{guix build}.
 Both are usually the same and correspond to the lowercase conversion of
 the project name chosen upstream, with underscores replaced with
 hyphens.  For instance, GNUnet is available as @code{gnunet}, and
 SDL_net as @code{sdl-net}.
 We do not add @code{lib} prefixes for library packages, unless these are
 already part of the official project name.  But @pxref{Python
 Modules} and @ref{Perl Modules} for special rules concerning modules for
 the Python and Perl languages.
 Font package names are handled differently, @pxref{Fonts}.
@node Version Numbers
@subsection Version Numbers
@cindex package version
 We usually package only the latest version of a given free software
 project.  But sometimes, for instance for incompatible library versions,
 two (or more) versions of the same package are needed.  These require
 different Scheme variable names.  We use the name as defined
 in @ref{Package Naming}
 for the most recent version; previous versions use the same name, suffixed
 by @code{-} and the smallest prefix of the version number that may
 distinguish the two versions.
 The name inside the package definition is the same for all versions of a
 package and does not contain any version number.
 For instance, the versions 2.24.20 and 3.9.12 of GTK+ may be packaged as follows:
@example
 (define-public gtk+
  (package
    (name "gtk+")
    (version "3.9.12")
    ...))
 (define-public gtk+-2
  (package
    (name "gtk+")
    (version "2.24.20")
    ...))
@end example
 If we also wanted GTK+ 3.8.2, this would be packaged as
@example
 (define-public gtk+-3.8
  (package
    (name "gtk+")
    (version "3.8.2")
    ...))
@end example
@c See <https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00425.html>,
@c for a discussion of what follows.
@cindex version number, for VCS snapshots
 Occasionally, we package snapshots of upstream's version control system
 (VCS) instead of formal releases.  This should remain exceptional,
 because it is up to upstream developers to clarify what the stable
 release is.  Yet, it is sometimes necessary.  So, what should we put in
 the @code{version} field?
 Clearly, we need to make the commit identifier of the VCS snapshot
 visible in the version string, but we also need to make sure that the
 version string is monotonically increasing so that @command{guix package
 --upgrade} can determine which version is newer.  Since commit
 identifiers, notably with Git, are not monotonically increasing, we add
 a revision number that we increase each time we upgrade to a newer
 snapshot.  The resulting version string looks like this:
@example
 2.0.11-3.cabba9e
  ^    ^    ^
  |    |    `-- upstream commit ID
  |    |
  |    `--- Guix package revision
  |
 latest upstream version
@end example
 It is a good idea to strip commit identifiers in the @code{version}
 field to, say, 7 digits.  It avoids an aesthetic annoyance (assuming
 aesthetics have a role to play here) as well as problems related to OS
 limits such as the maximum shebang length (127 bytes for the Linux
 kernel.)  It is best to use the full commit identifiers in
@code{origin}s, though, to avoid ambiguities.  A typical package
 definition may look like this:
@example
 (define my-package
  (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
        (revision "1"))          ;Guix package revision
    (package
      (version (git-version "0.9" revision commit))
      (source (origin
                (method git-fetch)
                (uri (git-reference
                      (url "git://example.org/my-package.git")
                      (commit commit)))
                (sha256 (base32 "1mbikn@dots{}"))
                (file-name (git-file-name name version))))
      ;; @dots{}
      )))
@end example
@node Synopses and Descriptions
@subsection Synopses and Descriptions
@cindex package description
@cindex package synopsis
 As we have seen before, each package in GNU@tie{}Guix includes a
 synopsis and a description (@pxref{Defining Packages}).  Synopses and
 descriptions are important: They are what @command{guix package
 --search} searches, and a crucial piece of information to help users
 determine whether a given package suits their needs.  Consequently,
 packagers should pay attention to what goes into them.
 Synopses must start with a capital letter and must not end with a
 period.  They must not start with ``a'' or ``the'', which usually does
 not bring anything; for instance, prefer ``File-frobbing tool'' over ``A
 tool that frobs files''.  The synopsis should say what the package
 is---e.g., ``Core GNU utilities (file, text, shell)''---or what it is
 used for---e.g., the synopsis for GNU@tie{}grep is ``Print lines
 matching a pattern''.
 Keep in mind that the synopsis must be meaningful for a very wide
 audience.  For example, ``Manipulate alignments in the SAM format''
 might make sense for a seasoned bioinformatics researcher, but might be
 fairly unhelpful or even misleading to a non-specialized audience.  It
 is a good idea to come up with a synopsis that gives an idea of the
 application domain of the package.  In this example, this might give
 something like ``Manipulate nucleotide sequence alignments'', which
 hopefully gives the user a better idea of whether this is what they are
 looking for.
 Descriptions should take between five and ten lines.  Use full
 sentences, and avoid using acronyms without first introducing them.
 Please avoid marketing phrases such as ``world-leading'',
 ``industrial-strength'', and ``next-generation'', and avoid superlatives
 like ``the most advanced''---they are not helpful to users looking for a
 package and may even sound suspicious.  Instead, try to be factual,
 mentioning use cases and features.
@cindex Texinfo markup, in package descriptions
 Descriptions can include Texinfo markup, which is useful to introduce
 ornaments such as @code{@@code} or @code{@@dfn}, bullet lists, or
 hyperlinks (@pxref{Overview,,, texinfo, GNU Texinfo}).  However you
 should be careful when using some characters for example @samp{@@} and
 curly braces which are the basic special characters in Texinfo
 (@pxref{Special Characters,,, texinfo, GNU Texinfo}).  User interfaces
 such as @command{guix package --show} take care of rendering it
 appropriately.
 Synopses and descriptions are translated by volunteers
@uref{http://translationproject.org/domain/guix-packages.html, at the
 Translation Project} so that as many users as possible can read them in
 their native language.  User interfaces search them and display them in
 the language specified by the current locale.
 To allow @command{xgettext} to extract them as translatable strings,
 synopses and descriptions @emph{must be literal strings}.  This means
 that you cannot use @code{string-append} or @code{format} to construct
 these strings:
@lisp
 (package
  ;; @dots{}
  (synopsis "This is translatable")
  (description (string-append "This is " "*not*" " translatable.")))
@end lisp
 Translation is a lot of work so, as a packager, please pay even more
 attention to your synopses and descriptions as every change may entail
 additional work for translators.  In order to help them, it is possible
 to make recommendations or instructions visible to them by inserting
 special comments like this (@pxref{xgettext Invocation,,, gettext, GNU
 Gettext}):
@example
 ;; TRANSLATORS: "X11 resize-and-rotate" should not be translated.
 (description "ARandR is designed to provide a simple visual front end
 for the X11 resize-and-rotate (RandR) extension. @dots{}")
@end example
@node Python Modules
@subsection Python Modules
@cindex python
 We currently package Python 2 and Python 3, under the Scheme variable names
@code{python-2} and @code{python} as explained in @ref{Version Numbers}.
 To avoid confusion and naming clashes with other programming languages, it
 seems desirable that the name of a package for a Python module contains
 the word @code{python}.
 Some modules are compatible with only one version of Python, others with both.
 If the package Foo compiles only with Python 3, we name it
@code{python-foo}; if it compiles only with Python 2, we name it
@code{python2-foo}. If it is compatible with both versions, we create two
 packages with the corresponding names.
 If a project already contains the word @code{python}, we drop this;
 for instance, the module python-dateutil is packaged under the names
@code{python-dateutil} and @code{python2-dateutil}.  If the project name
 starts with @code{py} (e.g.@: @code{pytz}), we keep it and prefix it as
 described above.
@subsubsection Specifying Dependencies
@cindex inputs, for Python packages
 Dependency information for Python packages is usually available in the
 package source tree, with varying degrees of accuracy: in the
@file{setup.py} file, in @file{requirements.txt}, or in @file{tox.ini}.
 Your mission, when writing a recipe for a Python package, is to map
 these dependencies to the appropriate type of ``input'' (@pxref{package
 Reference, inputs}).  Although the @code{pypi} importer normally does a
 good job (@pxref{Invoking guix import}), you may want to check the
 following check list to determine which dependency goes where.
@itemize
@item
 We currently package Python 2 with @code{setuptools} and @code{pip}
 installed like Python 3.4 has per default.  Thus you don't need to
 specify either of these as an input.  @command{guix lint} will warn you
 if you do.
@item
 Python dependencies required at run time go into
@code{propagated-inputs}.  They are typically defined with the
@code{install_requires} keyword in @file{setup.py}, or in the
@file{requirements.txt} file.
@item
 Python packages required only at build time---e.g., those listed with
 the @code{setup_requires} keyword in @file{setup.py}---or only for
 testing---e.g., those in @code{tests_require}---go into
@code{native-inputs}.  The rationale is that (1) they do not need to be
 propagated because they are not needed at run time, and (2) in a
 cross-compilation context, it's the ``native'' input that we'd want.
 Examples are the @code{pytest}, @code{mock}, and @code{nose} test
 frameworks.  Of course if any of these packages is also required at
 run-time, it needs to go to @code{propagated-inputs}.
@item
 Anything that does not fall in the previous categories goes to
@code{inputs}, for example programs or C libraries required for building
 Python packages containing C extensions.
@item
 If a Python package has optional dependencies (@code{extras_require}),
 it is up to you to decide whether to add them or not, based on their
 usefulness/overhead ratio (@pxref{Submitting Patches, @command{guix
 size}}).
@end itemize
@node Perl Modules
@subsection Perl Modules
@cindex perl
 Perl programs standing for themselves are named as any other package,
 using the lowercase upstream name.
 For Perl packages containing a single class, we use the lowercase class name,
 replace all occurrences of @code{::} by dashes and prepend the prefix
@code{perl-}.
 So the class @code{XML::Parser} becomes @code{perl-xml-parser}.
 Modules containing several classes keep their lowercase upstream name and
 are also prepended by @code{perl-}.  Such modules tend to have the word
@code{perl} somewhere in their name, which gets dropped in favor of the
 prefix.  For instance, @code{libwww-perl} becomes @code{perl-libwww}.
@node Java Packages
@subsection Java Packages
@cindex java
 Java programs standing for themselves are named as any other package,
 using the lowercase upstream name.
 To avoid confusion and naming clashes with other programming languages,
 it is desirable that the name of a package for a Java package is
 prefixed with @code{java-}.  If a project already contains the word
@code{java}, we drop this; for instance, the package @code{ngsjava} is
 packaged under the name @code{java-ngs}.
 For Java packages containing a single class or a small class hierarchy,
 we use the lowercase class name, replace all occurrences of @code{.} by
 dashes and prepend the prefix @code{java-}.  So the class
@code{apache.commons.cli} becomes package
@code{java-apache-commons-cli}.
@node Fonts
@subsection Fonts
@cindex fonts
 For fonts that are in general not installed by a user for typesetting
 purposes, or that are distributed as part of a larger software package,
 we rely on the general packaging rules for software; for instance, this
 applies to the fonts delivered as part of the X.Org system or fonts that
 are part of TeX Live.
 To make it easier for a user to search for fonts, names for other packages
 containing only fonts are constructed as follows, independently of the
 upstream package name.
 The name of a package containing only one font family starts with
@code{font-}; it is followed by the foundry name and a dash @code{-}
 if the foundry is known, and the font family name, in which spaces are
 replaced by dashes (and as usual, all upper case letters are transformed
 to lower case).
 For example, the Gentium font family by SIL is packaged under the name
@code{font-sil-gentium}.
 For a package containing several font families, the name of the collection
 is used in the place of the font family name.
 For instance, the Liberation fonts consist of three families,
 Liberation Sans, Liberation Serif and Liberation Mono.
 These could be packaged separately under the names
@code{font-liberation-sans} and so on; but as they are distributed together
 under a common name, we prefer to package them together as
@code{font-liberation}.
 In the case where several formats of the same font family or font collection
 are packaged separately, a short form of the format, prepended by a dash,
 is added to the package name.  We use @code{-ttf} for TrueType fonts,
@code{-otf} for OpenType fonts and @code{-type1} for PostScript Type 1
 fonts.
@node Coding Style
@section Coding Style
--- a/doc/guix.texi
+++ b/doc/guix.texi
@ -126,7 +126,6 @@ Project}.
 * Installing Debugging Files::  Feeding the debugger.
 * Security Updates::            Deploying security fixes quickly.
 * Package Modules::             Packages from the programmer's viewpoint.
 * Packaging Guidelines::        Growing the distribution.
 * Bootstrapping::               GNU/Linux built from scratch.
 * Porting::                     Targeting another platform or kernel.
 * Contributing::                Your help needed!
@ -282,17 +281,6 @@ Defining Services
 * Service Reference::           API reference.
 * Shepherd Services::           A particular type of service.
 Packaging Guidelines
 * Software Freedom::            What may go into the distribution.
 * Package Naming::              What's in a name?
 * Version Numbers::             When the name is not enough.
 * Synopses and Descriptions::   Helping users find the right package.
 * Python Modules::              A touch of British comedy.
 * Perl Modules::                Little pearls.
 * Java Packages::               Coffee break.
 * Fonts::                       Fond of fonts.
@end detailmenu
@end menu
@ -24180,456 +24168,6 @@ distribution.  The root of this dependency graph is a small set of
 bootstrap)} module.  For more information on bootstrapping,
@pxref{Bootstrapping}.
@node Packaging Guidelines
@chapter Packaging Guidelines
@cindex packages, creating
 The GNU distribution is nascent and may well lack some of your favorite
 packages.  This section describes how you can help make the distribution
 grow.  @xref{Contributing}, for additional information on how you can
 help.
 Free software packages are usually distributed in the form of
@dfn{source code tarballs}---typically @file{tar.gz} files that contain
 all the source files.  Adding a package to the distribution means
 essentially two things: adding a @dfn{recipe} that describes how to
 build the package, including a list of other packages required to build
 it, and adding @dfn{package metadata} along with that recipe, such as a
 description and licensing information.
 In Guix all this information is embodied in @dfn{package definitions}.
 Package definitions provide a high-level view of the package.  They are
 written using the syntax of the Scheme programming language; in fact,
 for each package we define a variable bound to the package definition,
 and export that variable from a module (@pxref{Package Modules}).
 However, in-depth Scheme knowledge is @emph{not} a prerequisite for
 creating packages.  For more information on package definitions,
@pxref{Defining Packages}.
 Once a package definition is in place, stored in a file in the Guix
 source tree, it can be tested using the @command{guix build} command
 (@pxref{Invoking guix build}).  For example, assuming the new package is
 called @code{gnew}, you may run this command from the Guix build tree
 (@pxref{Running Guix Before It Is Installed}):
@example
 ./pre-inst-env guix build gnew --keep-failed
@end example
 Using @code{--keep-failed} makes it easier to debug build failures since
 it provides access to the failed build tree.  Another useful
 command-line option when debugging is @code{--log-file}, to access the
 build log.
 If the package is unknown to the @command{guix} command, it may be that
 the source file contains a syntax error, or lacks a @code{define-public}
 clause to export the package variable.  To figure it out, you may load
 the module from Guile to get more information about the actual error:
@example
 ./pre-inst-env guile -c '(use-modules (gnu packages gnew))'
@end example
 Once your package builds correctly, please send us a patch
 (@pxref{Contributing}).  Well, if you need help, we will be happy to
 help you too.  Once the patch is committed in the Guix repository, the
 new package automatically gets built on the supported platforms by
@url{http://hydra.gnu.org/jobset/gnu/master, our continuous integration
 system}.
@cindex substituter
 Users can obtain the new package definition simply by running
@command{guix pull} (@pxref{Invoking guix pull}).  When
@code{@value{SUBSTITUTE-SERVER}} is done building the package, installing the
 package automatically downloads binaries from there
 (@pxref{Substitutes}).  The only place where human intervention is
 needed is to review and apply the patch.
@menu
 * Software Freedom::            What may go into the distribution.
 * Package Naming::              What's in a name?
 * Version Numbers::             When the name is not enough.
 * Synopses and Descriptions::   Helping users find the right package.
 * Python Modules::              A touch of British comedy.
 * Perl Modules::                Little pearls.
 * Java Packages::               Coffee break.
 * Fonts::                       Fond of fonts.
@end menu
@node Software Freedom
@section Software Freedom
@c Adapted from http://www.gnu.org/philosophy/philosophy.html.
@cindex free software
 The GNU operating system has been developed so that users can have
 freedom in their computing.  GNU is @dfn{free software}, meaning that
 users have the @url{http://www.gnu.org/philosophy/free-sw.html,four
 essential freedoms}: to run the program, to study and change the program
 in source code form, to redistribute exact copies, and to distribute
 modified versions.  Packages found in the GNU distribution provide only
 software that conveys these four freedoms.
 In addition, the GNU distribution follow the
@url{http://www.gnu.org/distros/free-system-distribution-guidelines.html,free
 software distribution guidelines}.  Among other things, these guidelines
 reject non-free firmware, recommendations of non-free software, and
 discuss ways to deal with trademarks and patents.
 Some otherwise free upstream package sources contain a small and optional
 subset that violates the above guidelines, for instance because this subset
 is itself non-free code.  When that happens, the offending items are removed
 with appropriate patches or code snippets in the @code{origin} form of the
 package (@pxref{Defining Packages}).  This way, @code{guix
 build --source} returns the ``freed'' source rather than the unmodified
 upstream source.
@node Package Naming
@section Package Naming
@cindex package name
 A package has actually two names associated with it:
 First, there is the name of the @emph{Scheme variable}, the one following
@code{define-public}.  By this name, the package can be made known in the
 Scheme code, for instance as input to another package.  Second, there is
 the string in the @code{name} field of a package definition.  This name
 is used by package management commands such as
@command{guix package} and @command{guix build}.
 Both are usually the same and correspond to the lowercase conversion of
 the project name chosen upstream, with underscores replaced with
 hyphens.  For instance, GNUnet is available as @code{gnunet}, and
 SDL_net as @code{sdl-net}.
 We do not add @code{lib} prefixes for library packages, unless these are
 already part of the official project name.  But @pxref{Python
 Modules} and @ref{Perl Modules} for special rules concerning modules for
 the Python and Perl languages.
 Font package names are handled differently, @pxref{Fonts}.
@node Version Numbers
@section Version Numbers
@cindex package version
 We usually package only the latest version of a given free software
 project.  But sometimes, for instance for incompatible library versions,
 two (or more) versions of the same package are needed.  These require
 different Scheme variable names.  We use the name as defined
 in @ref{Package Naming}
 for the most recent version; previous versions use the same name, suffixed
 by @code{-} and the smallest prefix of the version number that may
 distinguish the two versions.
 The name inside the package definition is the same for all versions of a
 package and does not contain any version number.
 For instance, the versions 2.24.20 and 3.9.12 of GTK+ may be packaged as follows:
@example
 (define-public gtk+
  (package
    (name "gtk+")
    (version "3.9.12")
    ...))
 (define-public gtk+-2
  (package
    (name "gtk+")
    (version "2.24.20")
    ...))
@end example
 If we also wanted GTK+ 3.8.2, this would be packaged as
@example
 (define-public gtk+-3.8
  (package
    (name "gtk+")
    (version "3.8.2")
    ...))
@end example
@c See <https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00425.html>,
@c for a discussion of what follows.
@cindex version number, for VCS snapshots
 Occasionally, we package snapshots of upstream's version control system
 (VCS) instead of formal releases.  This should remain exceptional,
 because it is up to upstream developers to clarify what the stable
 release is.  Yet, it is sometimes necessary.  So, what should we put in
 the @code{version} field?
 Clearly, we need to make the commit identifier of the VCS snapshot
 visible in the version string, but we also need to make sure that the
 version string is monotonically increasing so that @command{guix package
 --upgrade} can determine which version is newer.  Since commit
 identifiers, notably with Git, are not monotonically increasing, we add
 a revision number that we increase each time we upgrade to a newer
 snapshot.  The resulting version string looks like this:
@example
 2.0.11-3.cabba9e
  ^    ^    ^
  |    |    `-- upstream commit ID
  |    |
  |    `--- Guix package revision
  |
 latest upstream version
@end example
 It is a good idea to strip commit identifiers in the @code{version}
 field to, say, 7 digits.  It avoids an aesthetic annoyance (assuming
 aesthetics have a role to play here) as well as problems related to OS
 limits such as the maximum shebang length (127 bytes for the Linux
 kernel.)  It is best to use the full commit identifiers in
@code{origin}s, though, to avoid ambiguities.  A typical package
 definition may look like this:
@example
 (define my-package
  (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
        (revision "1"))          ;Guix package revision
    (package
      (version (git-version "0.9" revision commit))
      (source (origin
                (method git-fetch)
                (uri (git-reference
                      (url "git://example.org/my-package.git")
                      (commit commit)))
                (sha256 (base32 "1mbikn@dots{}"))
                (file-name (git-file-name name version))))
      ;; @dots{}
      )))
@end example
@node Synopses and Descriptions
@section Synopses and Descriptions
@cindex package description
@cindex package synopsis
 As we have seen before, each package in GNU@tie{}Guix includes a
 synopsis and a description (@pxref{Defining Packages}).  Synopses and
 descriptions are important: They are what @command{guix package
 --search} searches, and a crucial piece of information to help users
 determine whether a given package suits their needs.  Consequently,
 packagers should pay attention to what goes into them.
 Synopses must start with a capital letter and must not end with a
 period.  They must not start with ``a'' or ``the'', which usually does
 not bring anything; for instance, prefer ``File-frobbing tool'' over ``A
 tool that frobs files''.  The synopsis should say what the package
 is---e.g., ``Core GNU utilities (file, text, shell)''---or what it is
 used for---e.g., the synopsis for GNU@tie{}grep is ``Print lines
 matching a pattern''.
 Keep in mind that the synopsis must be meaningful for a very wide
 audience.  For example, ``Manipulate alignments in the SAM format''
 might make sense for a seasoned bioinformatics researcher, but might be
 fairly unhelpful or even misleading to a non-specialized audience.  It
 is a good idea to come up with a synopsis that gives an idea of the
 application domain of the package.  In this example, this might give
 something like ``Manipulate nucleotide sequence alignments'', which
 hopefully gives the user a better idea of whether this is what they are
 looking for.
 Descriptions should take between five and ten lines.  Use full
 sentences, and avoid using acronyms without first introducing them.
 Please avoid marketing phrases such as ``world-leading'',
 ``industrial-strength'', and ``next-generation'', and avoid superlatives
 like ``the most advanced''---they are not helpful to users looking for a
 package and may even sound suspicious.  Instead, try to be factual,
 mentioning use cases and features.
@cindex Texinfo markup, in package descriptions
 Descriptions can include Texinfo markup, which is useful to introduce
 ornaments such as @code{@@code} or @code{@@dfn}, bullet lists, or
 hyperlinks (@pxref{Overview,,, texinfo, GNU Texinfo}).  However you
 should be careful when using some characters for example @samp{@@} and
 curly braces which are the basic special characters in Texinfo
 (@pxref{Special Characters,,, texinfo, GNU Texinfo}).  User interfaces
 such as @command{guix package --show} take care of rendering it
 appropriately.
 Synopses and descriptions are translated by volunteers
@uref{http://translationproject.org/domain/guix-packages.html, at the
 Translation Project} so that as many users as possible can read them in
 their native language.  User interfaces search them and display them in
 the language specified by the current locale.
 To allow @command{xgettext} to extract them as translatable strings,
 synopses and descriptions @emph{must be literal strings}.  This means
 that you cannot use @code{string-append} or @code{format} to construct
 these strings:
@lisp
 (package
  ;; @dots{}
  (synopsis "This is translatable")
  (description (string-append "This is " "*not*" " translatable.")))
@end lisp
 Translation is a lot of work so, as a packager, please pay even more
 attention to your synopses and descriptions as every change may entail
 additional work for translators.  In order to help them, it is possible
 to make recommendations or instructions visible to them by inserting
 special comments like this (@pxref{xgettext Invocation,,, gettext, GNU
 Gettext}):
@example
 ;; TRANSLATORS: "X11 resize-and-rotate" should not be translated.
 (description "ARandR is designed to provide a simple visual front end
 for the X11 resize-and-rotate (RandR) extension. @dots{}")
@end example
@node Python Modules
@section Python Modules
@cindex python
 We currently package Python 2 and Python 3, under the Scheme variable names
@code{python-2} and @code{python} as explained in @ref{Version Numbers}.
 To avoid confusion and naming clashes with other programming languages, it
 seems desirable that the name of a package for a Python module contains
 the word @code{python}.
 Some modules are compatible with only one version of Python, others with both.
 If the package Foo compiles only with Python 3, we name it
@code{python-foo}; if it compiles only with Python 2, we name it
@code{python2-foo}. If it is compatible with both versions, we create two
 packages with the corresponding names.
 If a project already contains the word @code{python}, we drop this;
 for instance, the module python-dateutil is packaged under the names
@code{python-dateutil} and @code{python2-dateutil}.  If the project name
 starts with @code{py} (e.g.@: @code{pytz}), we keep it and prefix it as
 described above.
@subsection Specifying Dependencies
@cindex inputs, for Python packages
 Dependency information for Python packages is usually available in the
 package source tree, with varying degrees of accuracy: in the
@file{setup.py} file, in @file{requirements.txt}, or in @file{tox.ini}.
 Your mission, when writing a recipe for a Python package, is to map
 these dependencies to the appropriate type of ``input'' (@pxref{package
 Reference, inputs}).  Although the @code{pypi} importer normally does a
 good job (@pxref{Invoking guix import}), you may want to check the
 following check list to determine which dependency goes where.
@itemize
@item
 We currently package Python 2 with @code{setuptools} and @code{pip}
 installed like Python 3.4 has per default.  Thus you don't need to
 specify either of these as an input.  @command{guix lint} will warn you
 if you do.
@item
 Python dependencies required at run time go into
@code{propagated-inputs}.  They are typically defined with the
@code{install_requires} keyword in @file{setup.py}, or in the
@file{requirements.txt} file.
@item
 Python packages required only at build time---e.g., those listed with
 the @code{setup_requires} keyword in @file{setup.py}---or only for
 testing---e.g., those in @code{tests_require}---go into
@code{native-inputs}.  The rationale is that (1) they do not need to be
 propagated because they are not needed at run time, and (2) in a
 cross-compilation context, it's the ``native'' input that we'd want.
 Examples are the @code{pytest}, @code{mock}, and @code{nose} test
 frameworks.  Of course if any of these packages is also required at
 run-time, it needs to go to @code{propagated-inputs}.
@item
 Anything that does not fall in the previous categories goes to
@code{inputs}, for example programs or C libraries required for building
 Python packages containing C extensions.
@item
 If a Python package has optional dependencies (@code{extras_require}),
 it is up to you to decide whether to add them or not, based on their
 usefulness/overhead ratio (@pxref{Submitting Patches, @command{guix
 size}}).
@end itemize
@node Perl Modules
@section Perl Modules
@cindex perl
 Perl programs standing for themselves are named as any other package,
 using the lowercase upstream name.
 For Perl packages containing a single class, we use the lowercase class name,
 replace all occurrences of @code{::} by dashes and prepend the prefix
@code{perl-}.
 So the class @code{XML::Parser} becomes @code{perl-xml-parser}.
 Modules containing several classes keep their lowercase upstream name and
 are also prepended by @code{perl-}.  Such modules tend to have the word
@code{perl} somewhere in their name, which gets dropped in favor of the
 prefix.  For instance, @code{libwww-perl} becomes @code{perl-libwww}.
@node Java Packages
@section Java Packages
@cindex java
 Java programs standing for themselves are named as any other package,
 using the lowercase upstream name.
 To avoid confusion and naming clashes with other programming languages,
 it is desirable that the name of a package for a Java package is
 prefixed with @code{java-}.  If a project already contains the word
@code{java}, we drop this; for instance, the package @code{ngsjava} is
 packaged under the name @code{java-ngs}.
 For Java packages containing a single class or a small class hierarchy,
 we use the lowercase class name, replace all occurrences of @code{.} by
 dashes and prepend the prefix @code{java-}.  So the class
@code{apache.commons.cli} becomes package
@code{java-apache-commons-cli}.
@node Fonts
@section Fonts
@cindex fonts
 For fonts that are in general not installed by a user for typesetting
 purposes, or that are distributed as part of a larger software package,
 we rely on the general packaging rules for software; for instance, this
 applies to the fonts delivered as part of the X.Org system or fonts that
 are part of TeX Live.
 To make it easier for a user to search for fonts, names for other packages
 containing only fonts are constructed as follows, independently of the
 upstream package name.
 The name of a package containing only one font family starts with
@code{font-}; it is followed by the foundry name and a dash @code{-}
 if the foundry is known, and the font family name, in which spaces are
 replaced by dashes (and as usual, all upper case letters are transformed
 to lower case).
 For example, the Gentium font family by SIL is packaged under the name
@code{font-sil-gentium}.
 For a package containing several font families, the name of the collection
 is used in the place of the font family name.
 For instance, the Liberation fonts consist of three families,
 Liberation Sans, Liberation Serif and Liberation Mono.
 These could be packaged separately under the names
@code{font-liberation-sans} and so on; but as they are distributed together
 under a common name, we prefer to package them together as
@code{font-liberation}.
 In the case where several formats of the same font family or font collection
 are packaged separately, a short form of the format, prepended by a dash,
 is added to the package name.  We use @code{-ttf} for TrueType fonts,
@code{-otf} for OpenType fonts and @code{-type1} for PostScript Type 1
 fonts.
@node Bootstrapping
@chapter Bootstrapping