22.8.3 Номера версий

Обычно мы опакечиваем только последнюю версию данного программного обеспечения. Но иногда, например, при наличии несовместимых версий библиотек, нужны две (или более) версии одного пакета. Такая ситуация требует различных имён переменных в Scheme. Мы используем имя, определённое в Как называть пакеты, для самой последней версии; предыдущие же версии используют такое же имя с добавлением - и кратчайшим числом версии, что позволяет различать между двумя версиями.

Имя внутри описания пакета постоянно для всех версий пакета и не содержит номера версии.

Например, версии GTK+ 2.24.20 и 3.9.12 могут опакечиваться так:

(define-public gtk+
  (package
    (name "gtk+")
    (version "3.9.12")
    ...))
(define-public gtk+-2
  (package
    (name "gtk+")
    (version "2.24.20")
    ...))

Если нам также нужен GTK+ 3.8.2, он будет размещён в пакете

(define-public gtk+-3.8
  (package
    (name "gtk+")
    (version "3.8.2")
    ...))

Порой мы опакечиваем снимки исходников из системы контроля версий (СКВ) вместо официальных релизов. Такое следует делать в лишь порядке исключения, потому что только самим разработчики оригинальных программ решать, что является стабильным релизом. Тем не менее, иногда приходится это делать. Что же мы должны тогда пишем в поле версия?

Ясно, что нужно сделать идентификатор коммита снимка СКВ явным внутри строки версии, но мы также должны убедиться, что строка версии монотонно увеличивается, чтобы команда guix package --upgrade могла разобраться, какая версия новее. Поскольку идентификаторы коммитов, и особенно в Git, не увеличиваются монотонно, мы дописываем номер ревизии, который мы увеличиваем каждый раз, когда мы обновляем до нового снимка. В результате строка версии выглядит так:

2.0.11-3.cabba9e
  ^    ^    ^
  |    |    `-- ID коммита оригинала
  |    |
  |    `--- версия пакета Guix 
  |
последняя версия оригинала

Хорошая идея обрезать идентификаторы коммитов в поле version, скажем, до 7 цифр. Это позволяет избежать эстетическую неприятность (там, где это имеет значение), а также и проблемы с ограничениями ОС, как например, максимальная длина шебанга в заголовке скрипта (127 байт для ядра Linux). Существуют вспомогательные функции, дабы делать это в пакетах, используя git-fetch или hg-fetch (см. ниже). В поле источника — origin — лучшее всего использовать полный идентификатор коммита, чтобы избежать двоякости. Типичное описание пакета может выглядеть так:

(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…"))
                (file-name (git-file-name name version))))
      ;; …
      )))

Procedure: git-version VERSION REVISION COMMIT

Возвращает строку версии для пакетов используя git-fetch.

(git-version "0.2.3" "0" "93818c936ee7e2f1ba1b315578bde363a7d43d05")
⇒ "0.2.3-0.93818c9"

Procedure: hg-version VERSION REVISION CHANGESET

Возвращает строку версии для пакетов используя hg-fetch. Работает так же, как и git-version.