Archiv > Development
Wie kommen die Versionsnummern zustande?
maf:
Hallo Claus,
vielen Dank für Deine ausführliche Antwort! Vielleicht erklären sich unsere jeweiligen Sichtweisen auf die Versionsnummern aus unterschiedlichen Blickwinkeln. Du hast siehst die gesamte Distribution, die sich aus unterschiedlichen Quellen speist. Ich habe mehr meine Erfahrungen mit Debian-Paketen und -Versionsnummern im Bezug zu Paketentwicklung und -aktualisierung im Hinterkopf. Und ich weiß noch sehr wenig über MLD. Ich bitte deshalb lieber im Vorhinein um Nachsicht, falls ich mal zu keck oder gar anmaßend klingen sollte.
--- Quote from: clausmuus on November 04, 2014, 15:19:05 ---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.
--- End quote ---
Das geht natürlich garnicht. Da ist wohl ab jetzt eine strikte Urlaubssperre unausweichlich ;). Nein, im Ernst: Umso dankbarer bin ich natürlich, dass Du dich jetzt meiner (und all der anderen) Fragen angenommen hast. Ich hoffe, die Erholung hält eine Weile vor!
--- Quote from: clausmuus on November 04, 2014, 15:19:05 ---- 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.
--- End quote ---
Ah, verstehe. Die Projektgeschichte hatte ich nicht im Blick.
Meine Hauptkriterien für Versionsnummern wären vermutlich, dass eine Änderung der Quellen (Upstream oder native) und eine Änderung der Paketierung (Revision) stets zu einer neuen, "höheren" Versionsnummer führt, damit ein eindeutiges Verfahren für Upgrades umgesetzt werden kann. Wünschenswert schiene mir außerdem, dass es für einen Entwickler möglich ist, eigene Paketversionen zu erstellen (lokale Revision), die zwischen der aktuellen und der nächsten "offiziellen" Version liegen. Das klappt z.B. bei Debian recht gut. Bei MLD bin ich mir nicht so sicher. Aber vielleicht passt so ein Ansatz ja auch nicht so gut zu Deinen Vorstellungen, wie MLD funktioniert. Damit kenne ich mich - wie schon eingeräumt - (noch) nicht so gut aus.
--- Quote from: clausmuus on November 04, 2014, 15:19:05 ---- 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.
--- End quote ---
Dieses Teilthema würde ich gerne in den parallelen Thread zu python-gobject-2 auslagern.
--- Quote from: clausmuus on November 04, 2014, 15:19:05 ---- 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
--- End quote ---
Bei MLD-eigenen Paketen vertehe ich das (obwohl 1 vielleicht etwas selbstbewusster klänge als 0 :)). Aber es sind ziemlich viele Pakete dabei (nfs-*, diverse vdr-plugin-*, ...) die auch "nur" eine 0 als Versionsnummer haben und indirekt oder direkt auf externer Software basieren.
--- Quote from: clausmuus on November 04, 2014, 15:19:05 ---- 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.
--- End quote ---
Da verstehe ich leider noch vieles nicht. Z.B.: Die libs Pakete sind nicht im Repository enthalten? In einem libs Paket sind mehrere Bibliotheken? Kannst Du mir noch etwas auf die Sprünge helfen? Sonst muss ich mich durch die Makefiles wühlen. Bisher weiß ich eigentlich nur, dass ich ein Paket (python-gobject-2) erstellt habe und ziemlich viele Bibliothekspakete automatisch erstellt wurden ;). Warum mein selbstgebautes libc-Paket eine kleinere Versionsnummer hat als das ältere offizielle, habe ich leider noch nicht verstanden. Sollten die internen Mechanismen das nicht verhindern?
Schönen Gruß
Malte
clausmuus:
Hi,
--- Quote ---Meine Hauptkriterien für Versionsnummern wären vermutlich, dass eine Änderung der Quellen (Upstream oder native) und eine Änderung der Paketierung (Revision) stets zu einer neuen, "höheren" Versionsnummer führt, damit ein eindeutiges Verfahren für Upgrades umgesetzt werden kann
--- End quote ---
Das ist bereits jetzt der Fall. Oder ist Dir nen Paket aufgefallen, wo das nicht so ist (mal abgesehen vom python-gobject-2)?
--- Quote ---Wünschenswert schiene mir außerdem, dass es für einen Entwickler möglich ist, eigene Paketversionen zu erstellen (lokale Revision), die zwischen der aktuellen und der nächsten "offiziellen" Version liegen. Das klappt z.B. bei Debian recht gut.
--- End quote ---
Wie setzt Debian das denn um? Kannst Du nen Beispiel geben, für ne Versionsnummer des offiziellen Paketes und ner lokalen Version?
--- Quote ---Bei MLD-eigenen Paketen vertehe ich das (obwohl 1 vielleicht etwas selbstbewusster klänge als 0 :)). Aber es sind ziemlich viele Pakete dabei (nfs-*, diverse vdr-plugin-*, ...) die auch "nur" eine 0 als Versionsnummer haben und indirekt oder direkt auf externer Software basieren.
--- End quote ---
Ja, da besteht noch ein wenig Nachbesserungs Bedarf. Wenn Du magst, kannst Du gerne mal alle (oder erst mal einige exemplarische) Pakete raussuchen, bei denen das Deiner Meinung nach geändert werden sollte.
Und ja, vermutlich würde sich ne Version "1" anstelle der "0" besser machen :)
--- Quote ---Da verstehe ich leider noch vieles nicht. Z.B.: Die libs Pakete sind nicht im Repository enthalten? In einem libs Paket sind mehrere Bibliotheken? Kannst Du mir noch etwas auf die Sprünge helfen?
--- End quote ---
die libs pakete werden automatisch erstellt. Und zwar in dem moment, wenn beim bauen von Paketen festgestellt wird, das für dieses eine lib benötigt wird, die nicht in diesem Paket enthalten ist. Dann wird geschaut, aus welchem Debian Paket diese stammt und das entsprechende MLD Paket wird hergestellt und die benötigte lib hineingelegt. Werden weitere Libs dieses Debian lib Paketes benötigt, wird das MLD lib Paket um diese erweitert. So enthalten am Ende die libs Pakete nur genau das, was für die MLD benötigt wird.
Baust Du nun lokal nur ein einzelnes MLD Paket, enthalten im Anschluss deine lis Pakete nur das, was für genau dieses eine Paket benötigt wird. Das gleichnamige offizielle MLD Paket enthält aber möglicherweise wesentlich mehr libs, da ja noch andere Pakete gebaut wurden, die möglicherweise weitere Libs dieses lib Paketes benötigen.
Um nun zu erkennen, wann ein lib Paket geändert wurde (im Regelfall weil ne weitere lib hinzugekommen ist), wird die Anzahl de enthaltenen Libs gezählt und als MLD Versionsnummer verwendet.
Ich hoffe das war nun nicht zu verwirrend. Andernfalls werde ich Dir nen kleines Beispiel geben.
Claus
maf:
--- Quote from: clausmuus on November 05, 2014, 11:20:56 ---
--- Quote ---Meine Hauptkriterien für Versionsnummern wären vermutlich, dass eine Änderung der Quellen (Upstream oder native) und eine Änderung der Paketierung (Revision) stets zu einer neuen, "höheren" Versionsnummer führt, damit ein eindeutiges Verfahren für Upgrades umgesetzt werden kann
--- End quote ---
Das ist bereits jetzt der Fall. Oder ist Dir nen Paket aufgefallen, wo das nicht so ist (mal abgesehen vom python-gobject-2)?
--- End quote ---
Zumindest erkenne ich noch nicht, wie das in den Makefiles umgesetzt ist. Aber das kann sehr wohl daran liegen, dass ich die nicht gut genug verstehe.
Mein Verständnis ist bislang: Von welchen Quellpaketen (Ubuntu oder Raspbian) ein MLD Paket abhängt, steht in der Variablen deps. Die Versionsnummer des MLD Pakets wird aber nicht zwangsläufig aus der Versionsnummer der Quellpakete abgeleitet (bei mehreren wäre das auch bestimmt nicht trivial). Die MLD Module nutzten stattdessen unterschiedliche Verfahren, um eine Versionsnummer festzulegen. Meine Vermutung: Immer dann, wenn ein MLD Paket von (mindestens einem) Quellpaket abhängt, seine Versionsnummer aber statisch festgelegt wird, kann sich der Inhalt des Pakets ändern ohne dass sich seine Versionsnummer ändert. Aber auch wenn die Versionsnummer berechnet wird, ist das noch keine Garantie, dass alle Änderungen bei Quellpaketen berücksichtigt werden.
Viel hängt natürlich davon ab, was "abhängig" bedeutet. Ich stelle mir darunter vor, dass Dateien aus dem Quellpaket in das MLD Paket übernommen werden. Vielleicht stimmt das ja so pauschal garnicht.
Ich habe ein Skript 'check-versions' angehängt, das versucht, aufgrund der Einträge in den Makefiles Module zu identifzieren, die Probleme mit der Versionsnummer haben könnten. Das sind derzeit insbesondere Module die Abhängigkeiten definieren und keine Quelle (src_rule, src_url) definieren und ihre Version nicht berechnen.
Für diese Module werden dann ihre Versionsnummern und die Versionsnummer des Quellpakets (soweit verfügbar) ausgegeben. Es werden sicherlich viele Module dabei sein, bei denen Du, Claus, oder andere Entwickler sofort sagen: Da ist alles in Ordnung. Und andere Module, die vielleicht ein Problem haben könnten, werden durchs Raster fallen. Die aktuellen Heuristiken sind mit Sicherheit fehlerhaft. Meine Hoffnung ist auch nur, dass wir anhand des Skripts besser diskutieren können, wie die Vergabe von Versionsnummern funktioniert. Deshalb habe ich es recht großzügig kommentiert. Und vielleicht können wir es in ein paar Iterationszyklen so verbessern, das es weniger Fehler produziert.
Das Skript muss im Verzeichnis der Entwicklungsumgebung aufgerufen werden oder dieses Verzeichnis als Argument übergeben bekommen. Für jedes problematische Modul wird eine Zeile ausgeben. In der letzen Spalte steht entweder die Version des Quellpakets gleichen Namens oder, falls das nicht existiert aber das Paket genau eine 'dep' hat, dessen Versionsnummer (mit angehängtem Fragezeichen), andernfalls nur ein Fragezeichen.
--- Code: ---#! /bin/bash
# try to identify those modules that might have version number that
# does not change when the version of the underlying sofware changes
# modules this script does not identify (but should)
# - vdr-plugin-streamdev-client
# optional arguments
# - base directory of development environment
# setup
base=${1:-.}
release_version=4.0.1
case $(uname -m) in
x86) release_arch=32;;
x86_64) release_arch=64;;
armv6l) release_arch=rpi;;
*) echo $(basename $0): unknown architecture; exit 1;;
esac
release=${release_version}-${release_arch}
packages=/tmp/mld_packages_${release}
# retrieve release package list if not available
if [ ! -f $packages.vers ]; then
# determine architecture
# download package list
pkg_url=http://www.minidvblinux.de/download/${release}/files/base/Packages.gz
rm -f $packages $packages.gz
wget -qO $packages.gz $pkg_url
gunzip $packages.gz
# parse package list
awk '/^Package: / { package=$2 }
/^Version: / { version=$2 }
/^$/ { print package ": " version }
' $packages > $packages.vers
fi
# determine version of a package if available
pkg_version () {
name=$1
candidate=$(LANGUAGE=C apt-cache policy $name | awk '/Candidate/ { print $2 }')
if [ -n "$candidate" ] && [ "$candidate" != "(none)" ]; then
echo ${candidate%-*}
fi
}
# loop over modules to identiy potential version problems
find "$base" -mindepth 2 -maxdepth 2 -name Makefile -print | while read file; do
# don't look at libs
test $(dirname $file) == "$base/libs" && continue
# skip modules that don't use deps
grep -qE '^deps +:?=' $file || continue
# skip modules that define a source
grep -qE '^src_(rule|url) +:?=' $file && continue
# skip modules that define version_of
grep -qE '^version_of +:?=' $file && continue
# skip modules that compute version or latest_version unless using the python version
grep -E '^(latest_)?version +:?= \$\(shell' $file | grep -qv python && continue
# identify module
module=${file%/Makefile}
module=${module##*/}
# determine MLD package version
mld_version=$(awk '/^'$module':/ { print $2 }' $packages.vers)
mld_version=${mld_version%-*}
# determine source package version
source_version=$(pkg_version $module)
# guess version from single dep
if [ -z "$source_version" ] && [ $(awk '/^deps / { print NF }' $file) == "3" ]; then
dep=$(awk '/^deps / { print $3 }' $file)
source_version=$(pkg_version $dep)"?"
fi
# give up
if [ -z "$source_version" ]; then
source_version=?
fi
# report findings
echo $module: $mld_version - $source_version
done
--- End code ---
--- Quote from: clausmuus on November 05, 2014, 11:20:56 ---
--- Quote ---Bei MLD-eigenen Paketen vertehe ich das [...]. Aber es sind ziemlich viele Pakete dabei (nfs-*, diverse vdr-plugin-*, ...) die auch "nur" eine 0 als Versionsnummer haben und indirekt oder direkt auf externer Software basieren.
--- End quote ---
Ja, da besteht noch ein wenig Nachbesserungs Bedarf. Wenn Du magst, kannst Du gerne mal alle (oder erst mal einige exemplarische) Pakete raussuchen, bei denen das Deiner Meinung nach geändert werden sollte.
--- End quote ---
Vielleicht liefert check-versions ja irgendwann nutzbare Ergebnisse :).
--- Quote from: clausmuus on November 05, 2014, 11:20:56 ---
--- Quote ---Wünschenswert schiene mir außerdem, dass es für einen Entwickler möglich ist, eigene Paketversionen zu erstellen (lokale Revision), die zwischen der aktuellen und der nächsten "offiziellen" Version liegen. Das klappt z.B. bei Debian recht gut.
--- End quote ---
Wie setzt Debian das denn um? Kannst Du nen Beispiel geben, für ne Versionsnummer des offiziellen Paketes und ner lokalen Version?
--- End quote ---
Die genaue Beschreibung, wie Versionsnummer in Debian aufgebaut sind, liefert natürlich nur das Debian Policy Manual. Meine Kurzfassung: Die Versionsnummer besteht aus der Version der zugrundeliegenden Software (Upstream) und der Debian Revision. Beide sind durch ein "-" voneinander getrennt. Die Revision wird jedesmal erhöht, wenn eine Änderung bei der Paketerstellung vorgenommen wird. Wenn ich eine eigene Änderungen an einem Debian vornehme, modifiziere ich die Revision. Statt der Versionsnummer des offiziellen Pakets 47.11-3 erhält mein Paket dann z.B. die Version 47.11-3maf1. Wenn die nächste offizielle Version 47.11-4 freigegeben wird, ist sie höher als meine. Nach diesem Schema werden z.B. auch die Versionsnummern für Sicherheits-Updates vergeben, wenn sich die Version gepackten Software nicht ändert.
--- Quote from: clausmuus on November 05, 2014, 11:20:56 ---Ich hoffe das war nun nicht zu verwirrend. Andernfalls werde ich Dir nen kleines Beispiel geben.
--- End quote ---
Die Erklärung war sehr hilfreich. Danke! Und trotzdem: Ein Beispiel wäre toll ;).
Bei den libs-Paketen habe ich zugegebenermaßen den Verdacht, dass eigentlich kein Zusammenhang zwischen den Versionen der Quell-Bibliotheken und der Versionsnummer des Bibliothekspakets besteht. Vielleicht geht das ja auch überhaupt nicht. Aber meine Erfahrung beim Erstellen eines einzigen Pakets in einer frischen Entwicklungsumgebung verstehe ich mittlerweile so, dass dabei Bibliothekspakete erstellt werden (von denen dann auch Abhängigkeiten bestehen können), die vielleicht neuere Dateien enthalten als das gleichnamige Paket aus dem offiziellen Repository, aber eine kleinere Versionsnummer haben, weil sie aufgrund der Erfordernisse dieses speziellen Erstellungsprozesses weniger Teilbibliotheken enthalten.
Falls das zutrifft, dann liefert eine Änderung an einem einzelnen Paket nur dann ein Ergebnis, das konsistent mit dem Rest von MLD ist, wenn man das Paket in einer Entwicklungsumgebung erstellt, in der die anderen Pakete schon enthalten und erstellt worden sind. Ist das wirklich so?
Gruß,
Malte
clausmuus:
So, die custom Version Erweiterung habe ich schon mal eingebaut.
Claus
Navigation
[0] Message Index
[*] Previous page
Go to full version