22.4.3 Versionsnummern

Normalerweise stellen wir nur für die neueste Version eines Freie-Software-Projekts ein Paket bereit. Manchmal gibt es allerdings Fälle wie zum Beispiel untereinander inkompatible Bibliotheksversionen, so dass zwei (oder mehr) Versionen desselben Pakets angeboten werden müssen. In diesem Fall müssen wir verschiedene Scheme-Variablennamen benutzen. Wir benutzen dann für die neueste Version den Namen, wie er im Abschnitt Paketbenennung festgelegt wird, und geben vorherigen Versionen denselben Namen mit einem zusätzlichen Suffix aus - gefolgt vom kürzesten Präfix der Versionsnummer, mit dem noch immer zwei Versionen unterschieden werden können.

Der Name innerhalb der Paketdefinition ist hingegen derselbe für alle Versionen eines Pakets und enthält keine Versionsnummer.

Zum Beispiel können für GTK in den Versionen 2.24.20 und 3.9.12 Pakete wie folgt geschrieben werden:

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

Wenn wir auch GTK 3.8.2 wollten, würden wir das Paket schreiben als

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

Gelegentlich fügen wir auch Pakete für Snapshots aus dem Versionskontrollsystem des Anbieters statt formaler Veröffentlichungen zur Distribution hinzu. Das sollte die Ausnahme bleiben, weil die Entwickler selbst klarstellen sollten, welche Version als die stabile Veröffentlichung gelten sollte, ab und zu ist es jedoch notwendig. Was also sollten wir dann im version-Feld eintragen?

Offensichtlich muss der Bezeichner des Commits, den wir als Snapshot aus dem Versionskontrollsystem nehmen, in der Versionszeichenkette zu erkennen sein, aber wir müssen auch sicherstellen, dass die Version monoton steigend ist, damit guix package --upgrade feststellen kann, welche Version die neuere ist. Weil Commit-Bezeichner, insbesondere bei Git, nicht monoton steigen, müssen wir eine Revisionsnummer hinzufügen, die wir jedes Mal erhöhen, wenn wir das Paket auf einen neueren Snapshot aktualisieren. Die sich ergebende Versionszeichenkette sieht dann so aus:

2.0.11-3.cabba9e
  ^    ^    ^
  |    |    `-- Commit-ID beim Anbieter
  |    |
  |    `--- Revisionsnummer des Guix-Pakets
  |
die neueste Version, die der Anbieter veröffentlicht hat

Es ist eine gute Idee, die Commit-Bezeichner im version-Feld auf, sagen wir, 7 Ziffern zu beschränken. Das sieht besser aus (wenn das hier eine Rolle spielen sollte) und vermeidet Probleme, die mit der maximalen Länge von Shebangs zu tun haben (127 Bytes beim Linux-Kernel). Bei Paketen, die git-fetch oder hg-fetch benutzen, können Sie dafür Hilfsfunktionen nutzen (siehe unten). Am besten benutzen Sie in origins jedoch den vollständigen Commit-Bezeichner, um Mehrdeutigkeiten zu vermeiden. Eine typische Paketdefinition könnte so aussehen:

(define mein-paket
  (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
        (revision "1"))          ;Guix-Paketrevision
    (package
      (version (git-version "0.9" revision commit))
      (source (origin
                (method git-fetch)
                (uri (git-reference
                      (url "git://example.org/mein-paket.git")
                      (commit commit)))
                (sha256 (base32 "1mbikn…"))
                (file-name (git-file-name name version))))
      ;; …
      )))

Scheme-Prozedur: git-version VERSION REVISION COMMIT

Liefert die Zeichenkette für die Version bei Paketen, die git-fetch benutzen.

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

Scheme-Prozedur: hg-version VERSION REVISION ÄNDERUNGSSATZ

Liefert die Zeichenkette für die Version bei Paketen, die hg-fetch benutzen.<