Next: , Previous: , Up: Программный интерфейс   [Contents][Index]

6.2 Описание пакетов

The high-level interface to package definitions is implemented in the (guix packages) and (guix build-system) modules. As an example, the package definition, or recipe, for the GNU Hello package looks like this:

(define-module (gnu packages hello)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system gnu)
  #:use-module (guix licenses)
  #:use-module (gnu packages gawk))

(define-public hello
    (name "hello")
    (version "2.10")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnu/hello/hello-" version
    (build-system gnu-build-system)
    (arguments '(#:configure-flags '("--enable-silent-rules")))
    (inputs `(("gawk" ,gawk)))
    (synopsis "Hello, GNU world: An example GNU package")
    (description "Guess what GNU Hello prints!")
    (home-page "")
    (license gpl3+)))

Without being a Scheme expert, the reader may have guessed the meaning of the various fields here. This expression binds the variable hello to a <package> object, which is essentially a record (see Scheme records in GNU Guile Reference Manual). This package object can be inspected using procedures found in the (guix packages) module; for instance, (package-name hello) returns—surprise!—"hello".

With luck, you may be able to import part or all of the definition of the package you are interested in from another repository, using the guix import command (see Запуск guix import).

In the example above, hello is defined in a module of its own, (gnu packages hello). Technically, this is not strictly necessary, but it is convenient to do so: all the packages defined in modules under (gnu packages …) are automatically known to the command-line tools (see Пакетные модули).

There are a few points worth noting in the above package definition:

See Интерфейс package, for a full description of possible fields.

Once a package definition is in place, the package may actually be built using the guix build command-line tool (see Запуск guix build), troubleshooting any build failures you encounter (see Отладка ошибок сборки). You can easily jump back to the package definition using the guix edit command (see Запуск guix edit). See Принципы опакечивания, for more information on how to test package definitions, and Запуск guix lint, for information on how to check a definition for style conformance. Lastly, see Каналы, for information on how to extend the distribution by adding your own package definitions in a “channel”.

Finally, updating the package definition to a new upstream version can be partly automated by the guix refresh command (see Запуск guix refresh).

Behind the scenes, a derivation corresponding to the <package> object is first computed by the package-derivation procedure. That derivation is stored in a .drv file under /gnu/store. The build actions it prescribes may then be realized by using the build-derivations procedure (see Хранилище).

Scheme Procedure: package-derivation store package [system]

Return the <derivation> object of package for system (see Деривации).

package must be a valid <package> object, and system must be a string denoting the target system type—e.g., "x86_64-linux" for an x86_64 Linux-based GNU system. store must be a connection to the daemon, which operates on the store (see Хранилище).

Similarly, it is possible to compute a derivation that cross-builds a package for some other system:

Scheme Procedure: package-cross-derivation store package target [system] Return the <derivation>

object of package cross-built from system to target.

target must be a valid GNU triplet denoting the target hardware and operating system, such as "mips64el-linux-gnu" (see Specifying Target Triplets in Autoconf).

Packages can be manipulated in arbitrary ways. An example of a useful transformation is input rewriting, whereby the dependency tree of a package is rewritten by replacing specific inputs by others:

Scheme Procedure: package-input-rewriting replacements [rewrite-name] Return a procedure that, when passed a package,

replaces its direct and indirect dependencies (but not its implicit inputs) according to replacements. replacements is a list of package pairs; the first element of each pair is the package to replace, and the second one is the replacement.

Optionally, rewrite-name is a one-argument procedure that takes the name of a package and returns its new name after rewrite.

Consider this example:

(define libressl-instead-of-openssl
  ;; This is a procedure to replace OPENSSL by LIBRESSL,
  ;; recursively.
  (package-input-rewriting `((,openssl . ,libressl))))

(define git-with-libressl
  (libressl-instead-of-openssl git))

Here we first define a rewriting procedure that replaces openssl with libressl. Then we use it to define a variant of the git package that uses libressl instead of openssl. This is exactly what the --with-input command-line option does (see --with-input).

The following variant of package-input-rewriting can match packages to be replaced by name rather than by identity.

Scheme Procedure: package-input-rewriting/spec replacements

Return a procedure that, given a package, applies the given replacements to all the package graph (excluding implicit inputs). replacements is a list of spec/procedures pair; each spec is a package specification such as "gcc" or "guile@2", and each procedure takes a matching package and returns a replacement for that package.

The example above could be rewritten this way:

(define libressl-instead-of-openssl
  ;; Replace all the packages called "openssl" with LibreSSL.
  (package-input-rewriting/spec `(("openssl" . ,(const libressl)))))

The key difference here is that, this time, packages are matched by spec and not by identity. In other words, any package in the graph that is called openssl will be replaced.

A more generic procedure to rewrite a package dependency graph is package-mapping: it supports arbitrary changes to nodes in the graph.

Scheme Procedure: package-mapping proc [cut?]

Return a procedure that, given a package, applies proc to all the packages depended on and returns the resulting package. The procedure stops recursion when cut? returns true for a given package.

Next: , Previous: , Up: Программный интерфейс   [Contents][Index]