Archiv > Development

Wie kommen die Versionsnummern zustande?

(1/2) > >>

maf:
Hallo,

beim Einrichten einer Fernbedienung bin ich auf Schwierigkeiten mit dem Paket python-gobject-2 gestoßen. Um denen auf den Grund zu gehen, habe ich unter Raspbian Wheezy eine Entwicklungsumgebung eingerichtet und - nach einer Änderung im Makefile - das Paket neu gebaut.

Nun habe ich zwei Fragen zur Version des so erstellten Pakets:

* Das MLD-Paket hat die Version 2.7-3. Wo kommt diese Versionsnummer her? Die aktuelle Version des Pakets in Raspbian ist 2.28.6-10.
* Wie kann ich eine eigene Revision angeben, also z.B. 2.7-3maf1?
Danke,
Malte

maf:
Mittlerweile weiß ich zumindest ein bisschen mehr darüber, wie die Versionsnummern zustande kommen. Fast alles dazu findet sich in Makefile.default und natürlich in den Makefiles der einzelnen Module. Hier sind meine "Erkenntnisse" als Beitrag zur Diskussion oder gar Dokumentation. Alle Angaben hier beziehen sich auf MLD 4.0.1 für den Raspberry Pi. Für Fehler und Missverständniss möchte ich mich schon im Voraus entschuldigen :-)

Die Versionsnummer wird aus vier Komponenten gebildet:

--- Code: ---VERSION = $(version_prefix)$(version)$(version_suffix)-$(package_version)
--- End code ---
Wenn das Modul eine Abhängigkeit besitzt, kann auch die noch in die Versionsnummer eingehen:

--- Code: ---package_version := $(package_version)_$(depends_version)
--- End code ---

Die Variablen version_prefix und version_suffix werden kaum benutzt; derzeit nur von drei bzw. zwei Modulen.

Die Variable package_version ist so etwas wie die Revision in Debian. Allerdings wird sie i.d.R. automatisch gesetzt, und zwar auf die Anzahl der Git Commits im Projekt.

Die Variable version hat standardmäßig den Wert 0. In 59 Modulen wird ihr ein anderer, fester Wert zugewiesen. Erstaunlicherweise ziemlich oft 0 :-). Problematisch ist aus meiner Sicht, dass dieser Wert oft recht willkürlich oder veraltet scheint. Insbesondere dann, wenn man ihn mit der Versionsnummer des zugrundeliegenden Raspbian-Pakets vergleicht (z.B. dbus oder python3).

In 50 Modulen wird eine Version ermittelt. Zum Beispiel dadurch, dass das Modul ein Programm verpackt, das beim Aufruf seine Version liefert. Oder durch einen Aufruf von dpkg, der die Version des zugrundliegenden Raspbian Pakets liefert. Nicht verstanden habe ich, warum alle Python Module (python-*) die Python Versionsnummer (hier: 2.7) benutzen und nicht die Versionsnummer des zugrundeliegenden Pakets. Das bereitet mir z.B. Problem beim Upgrade von python-gobject-2.

In 64 Modulen schließlich werden die Variablen src_url bzw. src_rule gesetzt. Dann kann die aktuelle Version aus dem Quellarchiv abgeleitet werden.

Ein echtes Äquivalent für die Revision in Debian habe ich bislang nicht gefunden. Benutzt man version_suffix, dann landet dessen Wert in der Mitte der Versionsnummer. Die Anzahl der Commits im eigenen Repositoy kollidiert im Zweifel mit dem entsprechenden Wert in der Quelle.

Ich bin ja noch ganz neu in der MLD Entwicklung. Deshalb mag ich manches falsch verstanden haben. Doch zunächst einmal war ich überrascht, weil mir die Versionsnummern nicht sehr aussagekräftig schienen. Ich hatte eigentlich erwartet, dass sie stets eine Kombination aus der Versionsnummer des zugrundeliegenden Raspbian Pakets oder der Modulequelle (natürlich mit der Ausnahme MLD-eigener Module) und einer MLD-internen Zählung sein würden. Im Moment hätte ich die Befürchtung, dass Upgrades nicht immer richtig funktionieren.

skippy:
Hi Malte,

ich finde das toll, wie du in die MLD eingestiegen bist und dir viele Dinge selbst erarbeitet hast. Was die Entwicklung selbst betrifft, kann ich dir leider nicht helfen. Ich kann lediglich einige Fragen zur Anwendung selbst beantworten. Wie du sicher schon festgestellt hast, ist die Dokumentation bei der MLD noch nicht so ganz weit fortgeschritten  ;). Wir haben zwar ein Wiki, aber da ist noch viel zu tun, insbesondere was die Themen, "wie ist was in der MLD umgesetzt", betrifft.

Da du dir schon die Mühe gemacht hast, dich in die MLD einzuarbeiten und hier einige Dinge dazu aufgeschrieben hast, möchte ich dich bitten, das ins Wiki zu stellen. Da schauen die Entwickler auch immer mal rein und bereinigen bzw. ergänzen Sachen, die nicht so ganz passen. Damit erleichterst du anderen Einsteigern den Umgang und das Verständnis für die MLD. Falls du Probleme bzw. Fragen zum Wiki hast, helfe ich da gern.

Ich darf dich auch auf unseren Chat Mittwochs ab 21:00 Uhr aufmerksam machen. Da kannst du deine Fragen direkt mit den Entwicklern durchsprechen. Die Info dazu findest du bei den News vom 21.7.2013.

Vielen Dank und viele Grüße
skippy

maf:
Hallo skippy,

danke für Deine Ermunterung! Allerdings: Ich habe ja nicht nur meine Erkenntnisse zusammengefasst, sondern auch einige Fragen gestellt, auf die ich bislang leider keine Antwort erhalten habe. In meinem zweiten Thread, in dem es um Probleme beim Erstellen des Moduls python-gobject-2 geht, ist es genauso. Auf etwas mehr Unterstützung hatte schon gehofft.

Ungeachtet dessen möchte ich meinem ursprünglichen Beitrag noch in einem Punkt ergänzen. Für die Ermittlung der Version des Pakets für eine Bibliothek wird in libs/Makefile.libs

--- Code: ---package_version := $(shell find template -type l | wc -l)

--- End code ---
benutzt, also die Anzahl der Verweise im Unterverzeichnis template des Bibliotheksprojektes. Die Idee dahinter verstehe ich noch nicht. Beim Bau des Moduls python-object-2 hatte das bei mir jedenfalls den Effekt, dass mein Paket libc die Versionsnummer 2.13-10 erhielt, obwohl auf dem Zielrechner schon 2.13-11 installiert ist.

clausmuus:
Hi maf,

Ich war die letzten zwei Wochen im Urlaub, weshalb ich auf Deine Fragen nicht antworten konnte. Da es hier um tiefergreifende Interna der MLD geht, (und ich mir das System ausgedacht habe) konnten die anderen Entwickler Dir da auch keine tiefergehenden Antworten liefern.

Ich will nun mal versuchen etwas Licht in's Dunkel zu bringen:
- die statisch festgelegten Versionsnummern rühren größtenteils noch aus früheren MLD Versionen, wo es noch keinerlei Bezug zwischen Debian (Ubuntu/Raspian) Paketen und MLD Paketen gab. Die Verwendung der Debian Versionsnummer per dpkg habe ich erst mit der MLD-4 eingeführt. Bei der MLD-3 und früher wurde bestenfalls, wie von Dir bereits entdeckt, die Versionsnummer eines enthaltenen Tools genommen.
- Bei den python Paketen wurde die im Paket enthaltene Python Version (2.7) verwendet. Mir war nicht bewusst, das dies zu Problemen führen könnte. Es wäre aber sicher geschickter hier die volle Version 2.7.3 zu verwenden. Woher Du die 2.28.6-10 bezogen hast, ist mir allerdings nicht klar.
- Reine MLD Pakete die auf keinen externen Quellen beruhen verwenden die Versionsnummer 0, da es ja nichts gibt, was eine andere Versionsnummer rechtfertigen würde
- die package_version in den libs Paketen ist nen Sonderfall. Da die libs nur das enthalten, was benötigt wird, und alles andere was sonst noch in den korrespondierenden Debian Paketen enthalten ist weg lassen, brauchen wir hier eine Versionsnummer die erhöt wird, wenn das Paket weitere Libraries hinzubekommt. Zu beachten ist, das diese Pakete komplett zur Compilezeit erstellt werden, und nicht im MLD repository enthalten sind. Da es fast nie vorkommt, dass in einem libs Paket enthaltene libraries entfernt oder durch andere ersetzt werden, funktioniert diese Zählung recht brauchbar. Probleme können allerdings auftreten, wenn ein solches Paket auf einem anderem devel PC gebaut wird, und dort andere libs enthält, die im offiziellen Paket fehlen. Dann muss das Paket manuell auf dem MLD PC eingespielt werden, da dann ja die versionsnummer kleiner sein kann.

Hab ich irgendwas vergessen oder ist nochwas unklar?

Claus

Navigation

[0] Message Index

[#] Next page