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
Das ist bereits jetzt der Fall. Oder ist Dir nen Paket aufgefallen, wo das nicht so ist (mal abgesehen vom python-gobject-2)?
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.
#! /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
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.
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.
Vielleicht liefert check-versions ja irgendwann nutzbare Ergebnisse
.
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.
Wie setzt Debian das denn um? Kannst Du nen Beispiel geben, für ne Versionsnummer des offiziellen Paketes und ner lokalen Version?
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.
Ich hoffe das war nun nicht zu verwirrend. Andernfalls werde ich Dir nen kleines Beispiel geben.
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
Users Online