This section summarizes all the options available in
declarations (see Описание пакетов).
This is the data type representing a package recipe.
The name of the package, as a string.
The version of the package, as a string.
An object telling how the source code for the package should be acquired.
Most of the time, this is an
origin object, which denotes a file
fetched from the Internet (see Интерфейс origin). It can also be any
other “file-like” object such as a
local-file, which denotes a file
from the local file system (see
The build system that should be used to build the package (see Системы сборки).
The arguments that should be passed to the build system. This is a list, typically containing sequential keyword-value pairs.
These fields list dependencies of the package. Each one is a list of
tuples, where each tuple has a label for the input (a string) as its first
element, a package, origin, or derivation as its second element, and
optionally the name of the output thereof that should be used, which
"out" (see Пакеты со множественным выходом, for more
on package outputs). For example, the list below specifies three inputs:
`(("libffi" ,libffi) ("libunistring" ,libunistring) ("glib:bin" ,glib "bin")) ;the "bin" output of Glib
The distinction between
inputs is necessary
when considering cross-compilation. When cross-compiling, dependencies
inputs are built for the target architecture;
conversely, dependencies listed in
native-inputs are built for the
architecture of the build machine.
native-inputs is typically used to list tools needed at build time,
but not at run time, such as Autoconf, Automake, pkg-config, Gettext, or
guix lint can report likely mistakes in this area
(see Запуск guix lint).
propagated-inputs is similar to
inputs, but the
specified packages will be automatically installed alongside the package
they belong to (see
package, for information on how
guix package deals with
For example this is necessary when a C/C++ library needs headers of another
library to compile, or when a pkg-config file refers to another one via
Another example where
propagated-inputs is useful is for languages
that lack a facility to record the run-time search path akin to the
RUNPATH of ELF files; this includes Guile, Python, Perl, and more.
To ensure that libraries written in those languages can find library code
they depend on at run time, run-time dependencies must be listed in
propagated-inputs rather than
The list of output names of the package. See Пакеты со множественным выходом, for typical uses of additional outputs.
A list of
search-path-specification objects describing search-path
environment variables honored by the package.
This must be either
#f or a package object that will be used as a
replacement for this package. See grafts, for
A one-line description of the package.
A more elaborate description of the package.
The license of the package; a value from
(guix licenses), or a list
of such values.
The URL to the home-page of the package, as a string.
The list of systems supported by the package, as strings of the form
architecture-kernel, for example
location(default: source location of the
The source location of the package. It is useful to override this when inheriting from another package, in which case this field is not automatically corrected.
When used in the lexical scope of a package field definition, this identifier resolves to the package being defined.
The example below shows how to add a package as a native input of itself when cross-compiling:
(package (name "guile") ;; ... ;; When cross-compiled, Guile, for example, depends on ;; a native version of itself. Add it here. (native-inputs (if (%current-target-system) `(("self" ,this-package)) '())))
It is an error to refer to
this-package outside a package definition.