8.2.1 package Ссылка

В этом разделе перечислены все параметры, доступные в объявлениях package (see Описание пакетов).

Тип данных: package

Это тип данных, представляющий рецепт пакета.

name

Название пакета в виде строки.

версия

The version of the package, as a string. See Номера версий, for guidelines.

источник

Объект, указывающий, как должен быть получен исходный код пакета. В большинстве случаев это объект origin, который обозначает файл, полученный из Интернета (see Интерфейс origin). Это также может быть любой другой объект, подобный файлу, например local-file, который представляет собой файл из локальной файловой системы (see local-file).

система сборки

Система сборки, которую следует использовать для сборки пакета (see Системы сборки).

arguments (default: '())

Аргументы, которые следует передать системе сборки. Это список, обычно содержащий последовательные пары ключевого слова и значения.

inputs (default: '())

native-inputs (default: '())

propagated-inputs (default: '())

These fields list dependencies of the package. Each element of these lists is either a package, origin, or other “file-like object” (see G-Expressions); to specify the output of that file-like object that should be used, pass a two-element list where the second element is the output (see Пакеты со множественным выходом, for more on package outputs). For example, the list below specifies three inputs:

(list libffi libunistring
      `(,glib "bin"))      ;the "bin" output of GLib

In the example above, the "out" output of libffi and libunistring is used.

Compatibility Note: Until version 1.3.0, input lists were 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 defaults to "out". For example, the list below is equivalent to the one above, but using the old input style:

;; Old input style (deprecated).
`(("libffi" ,libffi)
  ("libunistring" ,libunistring)
  ("glib:bin" ,glib "bin"))  ;the "bin" output of GLib

This style is now deprecated; it is still supported but support will be removed in a future version. It should not be used for new package definitions. See Invoking guix style, on how to migrate to the new style.

Различие между native-inputs и inputs необходимо при рассмотрении кросс-компиляции. При кросс-компиляции зависимости, перечисленные в input, создаются для архитектуры target; и наоборот, зависимости, перечисленные в native-inputs, созданы для архитектуры машины, выполняющей сборку.

native-inputs обычно используется для перечисления инструментов, необходимых во время сборки, но не во время выполнения, таких как Autoconf, Automake, pkg-config, Gettext или Bison. guix lint может сообщить о вероятных ошибках в этой области (see Запуск guix lint).

Наконец, propagated-inputs похоже на inputs, но указанные пакеты будут автоматически установлены в профили (see the role of profiles in Guix) вместе с пакетом, которому они принадлежат (see guix package, for information on how guix package deals with propagated inputs).

Например, это необходимо при упаковке библиотеки C/C++, которой для компиляции требуются заголовки другой библиотеки, или когда файл pkg-config ссылается на другое поле через его Requires.

Другой пример использования propagated-inputs - это языки, в которых отсутствует возможность записывать путь поиска во время выполнения, аналогичный RUNPATH файлов ELF; сюда входят Guile, Python, Perl и другие. При упаковке библиотек, написанных на этих языках, убедитесь, что они могут найти код библиотеки, от которого они зависят, во время выполнения, указав зависимости времени выполнения в propagated-inputs, а не в inputs.

outputs (default: '("out"))

Список выходных имен пакета. See Пакеты со множественным выходом, для типичного использования дополнительных выходов.

native-search-paths (default: '())

search-paths (по умолчанию: '())

A list of search-path-specification objects describing search-path environment variables honored by the package. See Search Paths, for more on search path specifications.

As for inputs, the distinction between native-search-paths and search-paths only matters when cross-compiling. In a cross-compilation context, native-search-paths applies exclusively to native inputs whereas search-paths applies only to host inputs.

Packages such as cross-compilers care about target inputs—for instance, our (modified) GCC cross-compiler has CROSS_C_INCLUDE_PATH in search-paths, which allows it to pick .h files for the target system and not those of native inputs. For the majority of packages though, only native-search-paths makes sense.

replacement (по умолчанию: #f)

Это должен быть либо #f, либо объект пакета, который будет использоваться как замена для этого пакета. See grafts, чтобы узнать подробности.

синопсис

Описание пакета в одну строку.

описание

Более подробное описание пакета.

лицензия

Лицензия пакета; значение из (guix licenses) или список таких значений.

главная страница

URL-адрес домашней страницы пакета в виде строки.

port (default: 22)

Список систем, поддерживаемых пакетом, в виде строк вида architecture-kernel, например "x86_64-linux".

location (по умолчанию: исходное местоположение формы package)

Исходное расположение пакета. Это полезно переопределить при наследовании от другого пакета, и в этом случае это поле не корректируется автоматически.

Scheme Syntax: this-package

При использовании в lexical scope определения поля пакета этот идентификатор преобразуется в определяемый пакет.

В приведенном ниже примере показано, как добавить пакет в качестве собственного ввода при кросс-компиляции:

(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)
                     (list this-package)
                     '())))

Ссылка на this-package вне определения пакета является ошибкой.

The following helper procedures are provided to help deal with package inputs.

Scheme Procedure: lookup-package-input package name

Scheme Procedure: lookup-package-native-input package name

Scheme Procedure: lookup-package-propagated-input package name

Scheme Procedure: lookup-package-direct-input package name

Look up name among package’s inputs (or native, propagated, or direct inputs). Return it if found, #f otherwise.

name is the name of a package depended on. Here’s how you might use it:

(use-modules (guix packages) (gnu packages base))

(lookup-package-direct-input coreutils "gmp")
⇒ #<package gmp@6.2.1 …>

In this example we obtain the gmp package that is among the direct inputs of coreutils.

Sometimes you will want to obtain the list of inputs needed to develop a package—all the inputs that are visible when the package is compiled. This is what the package-development-inputs procedure returns.

Scheme Procedure: package-development-inputs package [system] [#:target #f] Return the list of inputs required by

package for development purposes on system. When target is true, return the inputs needed to cross-compile package from system to triplet, where triplet is a triplet such as "aarch64-linux-gnu".

Note that the result includes both explicit inputs and implicit inputs—inputs automatically added by the build system (see Системы сборки). Let us take the hello package to illustrate that:

(use-modules (gnu packages base) (guix packages))

hello
⇒ #<package hello@2.10 gnu/packages/base.scm:79 7f585d4f6790>

(package-direct-inputs hello)
⇒ ()

(package-development-inputs hello)
⇒ (("source" …) ("tar" #<package tar@1.32 …>) …)

In this example, package-direct-inputs returns the empty list, because hello has zero explicit dependencies. Conversely, package-development-inputs includes inputs implicitly added by gnu-build-system that are required to build hello: tar, gzip, GCC, libc, Bash, and more. To visualize it, guix graph hello would show you explicit inputs, whereas guix graph -t bag hello would include implicit inputs (see Запуск guix graph).

Поскольку пакеты являются обычными Scheme объектами, которые захватывают полный граф зависимостей и связанные процедуры сборки, часто бывает полезно написать процедуры, которые принимают пакет и возвращают его измененную версию в соответствии с некоторыми параметрами. Ниже приведены несколько примеров.

Процедура Scheme: inferior-package-location package

Вернуть вариант package, в котором используется toolchain вместо стандартного набора инструментов GNU C/C++. toolchain должен быть списком входов (кортежи меток/пакетов), обеспечивающих эквивалентную функциональность, например, пакет gcc-toolchain.

Пример ниже возвращает вариант пакета hello, созданный с помощью GCC 10.x и остальной части GNU утилит (Binutils и библиотеки GNU C) вместо цепочки инструментов по умолчанию:

(let ((toolchain (specification->package "gcc-toolchain@10")))
  (package-with-c-toolchain hello `(("toolchain" ,toolchain))))

Инструменты сборки являются частью неявных входных данных пакетов - обычно они не указываются как часть различных полей “входных данных”, а вместо этого извлекается системой сборки. Следовательно, эта процедура работает путем изменения системы сборки package, так что она использует toolchain вместо значений по умолчанию. Системы сборки, чтобы узнать больше о системах сборки.