Versionsnummerndurcheinander bei Debian

Florian Weimer

Bei Debian wird jedem Softwarepaket eine Versionsnummer zugeordnet, um neuere Pakete von älteren zu unterscheiden. Seltsamerweise gibt es aber kaum zwei Programme in Debian, die sich einig sind, was die zeitliche Abfolge der Versionen betrifft. Solche Abweichungen können im Extremfall zu Inkonsistenzen in der Paketverwaltung führen.

Das Verfahren

Debian-Versionen bestehen grob aus drei Teilen: Am Anfang steht die sogenannte Epoche (eine Zahl), danach folgt ein Doppelpunkt „:“, danach die Upstream-Version, danach die Debian-interne Revisionsnummer, die durch einen Bindestrich „-“ abgetrennt wird. Die Epoche kann auch weggelassen werden (samt Doppelpunkt; das ist sogar der Regelfall), dann wird Null angenommen.

Die Reihenfolge der Sortierung der Versionsnummern ist im wesentlichen lexikographisch. Aufeinanderfolgende Ziffern in der Versionsnummer werden en bloc als Zahl verglichen, so daß „12“ größer als „9“ ist (was in einer rein lexikographischen Ordnung nicht der Fall wäre). Außerdem werden ein paar Sonderzeichen speziell behandelt.

Das Verfahren wird genauer in der Debian Policy <http://www.us.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version> beschrieben. Aber offenbar nicht genau genug.

Die Implementierungen

Drei verschiedene Implementierungen dieses Algorithmus sind mir in letzter Zeit untergekommen, mit sich in Grenzfällen unterscheidendem Verhalten:

Glücklicherweise scheinen diese Abweichungen keine Rolle zu spielen, zumindest sind aus der Praxis noch keine Probleme daraus entstanden. Ärgerlich ist es trotzdem, wenn man den Versionsvergleich in eigener Software benötigt und das irgendwie implementieren muß.

Meine erste Python-Implementierung hatte den Fehler, daß sie die Sonderzeichen wie „.“ nicht gesondert behandelte. Das nahm ich als Warnung und wollte daher unbedingt offiziellen Code wiederverwenden (und zwar auf die gute, alte Freie-Software-Methode: per Cut & Paste). Mein Erstaunen war folglich groß, als ich die Abweichung zwischen APT und dpkg entdeckte, zumal der APT-Code auf besagte Weise aus dem dpkg-Code entstanden war. Im Moment verwende ich jedenfalls die Variante aus APT, da sie sich besser integrieren läßt und das Problem mit den großen Epochen einen kleinen Eingriff in dpkg erfordert, bevor es behoben werden kann. Ein Zweizeiler ist das nicht, vielmehr muß beispielsweise der für APT geänderte Code wieder zurückportiert werden.

Die Korrektur

Da sich das Verhalten von dpkg und APT sich nicht kurzfristig angleichen läßt, erscheint es sinnvoll, Versionsnummern mit bekanntermaßen widersprüchlichen Interpretationen zu verbieten. Debian Bug #336342 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336342> versucht, dies zu erreichen. Langfristig sollten natürlich alle Programme so angepaßt werden, daß sie dasselbe Verhalten zeigen. Derartige Änderungen werden aber erst nach der nächsten offiziellen Debian-Version wirksam (und wer Debian kennt, weiß, daß das wirklich längere Zeiträume sind), weil bei veröffentlichten Versionen solche doch etwas pikanten Änderungen völlig zurecht tabu sind.

Ich verstehe dieses kleine Abenteuer auch als Warnung, auch bei simplen Algorithmen stets das Verhalten in den Grenzbereichen über sorgfältige ausgewählte Tests festzunageln. Selbst wenn die Spezifikation ziemlich eindeutig ist, gibt es trotzdem jede Menge Abweichungen in den Details. Andererseits glaube ich nicht, daß hier das prinzipielle Problem bei der Wiederverwertung durch Cut & Paste liegt. Die Schnittstellenanpassung wäre auch bei moderneren Entwicklungsmethoden fällig gewesen, so daß sich vielleicht eine ähnliche Abweichung eingeschlichen hätte.

PS: Wie man auf so etwas stößt? Das geschieht, wenn man versionsbasierte Sicherheitshinweise für Debian implementiert.

Revisions


Florian Weimer
Home Blog (DE) Blog (EN) Impressum RSS Feeds