8.2 Definindo pacotes

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
  (package
    (name "hello")
    (version "2.10")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnu/hello/hello-" version
                                  ".tar.gz"))
              (sha256
               (base32
                "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
    (build-system gnu-build-system)
    (arguments '(#:configure-flags '("--enable-silent-rules")))
    (inputs (list gawk))
    (synopsis "Hello, GNU world: An example GNU package")
    (description "Guess what GNU Hello prints!")
    (home-page "https://www.gnu.org/software/hello/")
    (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 (veja Scheme records em 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 (veja Invoking 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 (veja Módulos de pacote).

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

• The source field of the package is an <origin> object (veja origin Reference, for the complete reference). Here, the url-fetch method from (guix download) is used, meaning that the source is a file to be downloaded over FTP or HTTP.

  The mirror://gnu prefix instructs url-fetch to use one of the GNU mirrors defined in (guix download).

  The sha256 field specifies the expected SHA256 hash of the file being downloaded. It is mandatory, and allows Guix to check the integrity of the file. The (base32 …) form introduces the base32 representation of the hash. You can obtain this information with guix download (veja Invocando guix download) and guix hash (veja Invocando guix hash).

  When needed, the origin form can also have a patches field listing patches to be applied, and a snippet field giving a Scheme expression to modify the source code.

• The build-system field specifies the procedure to build the package (veja Sistemas de compilação). Here, gnu-build-system represents the familiar GNU Build System, where packages may be configured, built, and installed with the usual ./configure && make && make check && make install command sequence.

  When you start packaging non-trivial software, you may need tools to manipulate those build phases, manipulate files, and so on. Veja Construir utilitários, for more on this.

• The arguments field specifies options for the build system (veja Sistemas de compilação). Here it is interpreted by gnu-build-system as a request run configure with the --enable-silent-rules flag.

  What about these quote (') characters? They are Scheme syntax to introduce a literal list; ' is synonymous with quote. Sometimes you’ll also see ` (a backquote, synonymous with quasiquote) and , (a comma, synonymous with unquote). Veja quoting em GNU Guile Reference Manual, for details. Here the value of the arguments field is a list of arguments passed to the build system down the road, as with apply (veja apply em GNU Guile Reference Manual).

  The hash-colon (#:) sequence defines a Scheme keyword (veja Keywords em GNU Guile Reference Manual), and #:configure-flags is a keyword used to pass a keyword argument to the build system (veja Coding With Keywords em GNU Guile Reference Manual).

• The inputs field specifies inputs to the build process—i.e., build-time or run-time dependencies of the package. Here, we add an input, a reference to the gawk variable; gawk is itself bound to a <package> object.

  Note that GCC, Coreutils, Bash, and other essential tools do not need to be specified as inputs here. Instead, gnu-build-system takes care of ensuring that they are present (veja Sistemas de compilação).

  However, any other dependencies need to be specified in the inputs field. Any dependency not specified here will simply be unavailable to the build process, possibly leading to a build failure.

Veja package Reference, for a full description of possible fields.

Indo além: Intimidated by the Scheme language or curious about it? The Cookbook has a short section to get started that recaps some of the things shown above and explains the fundamentals. Veja A Scheme Crash Course em GNU Guix Cookbook, for more information.

Once a package definition is in place, the package may actually be built using the guix build command-line tool (veja Invocando guix build), troubleshooting any build failures you encounter (veja Depurando falhas de compilação). You can easily jump back to the package definition using the guix edit command (veja Invocando guix edit). Veja Diretrizes de empacotamento, for more information on how to test package definitions, and Invocando guix lint, for information on how to check a definition for style conformance. Lastly, veja Canais, 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 (veja Invocando 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 (veja O armazém).

Procedure: package-derivation store package [system]

Return the <derivation> object of package for system (veja Derivações).

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 (veja O armazém).

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

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 "aarch64-linux-gnu" (veja Specifying Target Triplets em Autoconf).

Once you have package definitions, you can easily define variants of those packages. Veja Definindo variantes de pacote, for more on that.

• package Reference
• origin Reference