Hallo Christian, *,
SuSE hat einen Patch-mechanismus, der aber leider nicht kompatibel mit
den Standard-rpm format ist (AFAIK andere Datenbankstrukture u.ä.)
ich möchte das Update-Problem mal ein bißchen weiter beleuchten. Es ist
sicher richtig, daß der SuSE Update-Mechanismus, bei dem einfach ein
Patch-RPM über ein bestehendes bereits installiertes RPM eingespielt wird,
bei den RPM basierten Distributionen noch nicht weit verbreitet ist.
Allerdings ist das nicht die einzige Möglichkeit. Sowohl für SuSE als auch
für andere RPM basierte Distros gibt es das Package "deltarpm", z.B. unter
<http://dag.wieers.com/packages/deltarpm> bzw. kann man sich das aus den
Sourcen unter <http://suse.inode.at/projects/deltarpm> bauen. Dort sind
einige interessante Tools enthalten:
makedeltarpm oldrpm newrpm deltarpm
applydeltarpm -r oldrpm deltarpm newrpm
Mit 'makedeltarpm' läßt sich aus einem alten und einem neuen RPM Package
ein Delta erzeugen. Mittels 'applydeltarpm' wird aus einem alten RPM
Package und dem Delta das neue RPM.
Bei letzterem neuen RPM handelt es sich um eine binär 100%ig identische
Fassung des neuen Original-Packages, welches somit auch auf jeder
Distribution problemlos eingesetzt werden kann.
Ich habe mir erlaubt, einige Tests durchzuführen zwischen OOo 2.0.1 und
der jetzigen OOo 2.0.2 RC 4 Fassung:
OOo_2.0.1_LinuxIntel_de.tar.gz 110.861.951 Bytes
OOo_2.0.2rc4_060227_LinuxIntel_de.tar.gz 124.084.085 Bytes (*)
openoffice.org.patch.tar.gz 39.392.225 Bytes
(*) Um fair zu bleiben, habe ich die jre entfernt, die bei OOo 2.0.1 noch
nicht drin war (Originalsize mit jre war 142.591.488 Bytes)
Es lassen sich also vgl. mit der vollen OOo 2.0.2 RC 4 satte 68%
Übertragungsvolumen einsparen, wenn RPM Patches verwendet werden.
Ich habe noch eine weitere Untersuchung ähnlicher Art gemacht:
Angenommen die OOo RPMs wurden ohne Verwendung der Haupt-RPM Database in
ein Unterverzeichnis installiert (hier z.B. mit Pavel's install Skript).
Anschließend wird das Ergebnis der Installation in ein unkomprimiertes
tarball verpackt (**). Es ergibt sich dann folgendes:
ooo_2.0.1.tar 296.693.760 Bytes
ooo_2.0.2.rc4.tar 321.802.240 Bytes
Hierauf lasse man dann das Tool 'xdelta' los (<http://www.xdelta.org>),
mit dem man einen Binärpatch erzeugen kann, der einen vom einen tarball
zum anderen bringt:
xdelta delta ooo_2.0.1.tar ooo_2.0.2.rc4.tar tarpatch
Dann ergibt sich
tarpatch 55.837.224 Bytes
Hier ist das Verhältnis nicht mehr ganz so gut, aber auch hier ergeben
sich immerhin noch 55% Ersparnis.
(**) Die Methode mit den unkomprimierten tarballs wurde gewählt, weil
xdelta auf komprimierten Binaries wie z.B. intern schon komprimierten RPM
Packages designbasiert nur schlechte Resultate liefert, da wegen der durch
die Komprimierung erfolgende Datenverwirbelung die binären Diff
Algorithmen leider nicht mehr greifen. xdelta komprimiert die
resultierende Patch-Datei schon selbst, eine weitere Komprimierung ist
sinnlos.
Gruß,
Guido
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
