Next: Краткие обзоры и описания, Previous: Как называть пакеты, Up: Принципы опакечивания [Contents][Index]
Обычно мы опакечиваем только последнюю версию некоторого программного
обеспечения. Но иногда, например, при наличии несовместимых версий
библиотек, нужны две (или более) версии одного пакета. Это требует разных
имён переменных 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, он будет размещён в пакете
Порой мы опакечиваем снепшоты исходников из системы контроля версий (СКВ)
вместо официальных релизов. Это остаётся исключением, потому что только
разработчики оригинальных программ решают, что является стабильным
релизом. Иногда это имеет значение. Что же мы должны писать в поле
версия
?
Ясно, что нужно сделать отображение идентификатора коммита снепшота СКВ
внутри строки версии, но мы также должны убедиться, что строка "версия"
монотонно увеличивается, так чтобы guix package --upgrade
могла
определить, какая версия новее. Так как идентификаторы коммитов, что точно,
Git, не увеличиваются, мы добавляем номер ревизии, которую мы увеличиваем
каждый раз, когда мы обновляем до нового снепшота. Результирующая строка
версии выглядит так:
2.0.11-3.cabba9e ^ ^ ^ | | `-- ID коммита оригинала | | | `--- версия пакета Guix | последняя версия оригинала
It is a good idea to strip commit identifiers in the version
field
to, say, 7 digits. It avoids an aesthetic annoyance (assuming aesthetics
have a role to play here) as well as problems related to OS limits such as
the maximum shebang length (127 bytes for the Linux kernel). There are
helper functions for doing this for packages using git-fetch
or
hg-fetch
(see below). It is best to use the full commit identifiers
in origin
s, though, to avoid ambiguities. A typical package
definition may look like this:
(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))))
;; …
)))
Return the version string for packages using git-fetch
.
(git-version "0.2.3" "0" "93818c936ee7e2f1ba1b315578bde363a7d43d05") ⇒ "0.2.3-0.93818c9"
Return the version string for packages using hg-fetch
. It works in
the same way as git-version
.
Next: Краткие обзоры и описания, Previous: Как называть пакеты, Up: Принципы опакечивания [Contents][Index]