Openoffice 2.0.2 als Binäries
Ralf Lehmeier
Gibt es eigentlich ausführbare Binäries von Openoffice?
Ich kenne Sie von Mozilla aus und fand es immer sehr praktisch das
einfach der ganze Unterbau ausgetauscht werden kann ohne das man immer
wieder die neuen Profile anlegen und nicht jeder wieder seine Daten
wieder neu eingeben muß .
Danke im vorraus.
MfG R.Lehmeier
Guido Ostkamp
Ralf Lehmeier <r.leh...@freenet.de> wrote:
> Gibt es eigentlich ausführbare Binäries von Openoffice?
Du wirfst da ein paar Begriffe durcheinander. Ein "ausführbares
Binary" ist einfach ein Programm und natürlich enthält OpenOffice.org
ausführbare Binaries. Diese können aber immer noch eine Umgebung
erforderlich machen.
Was Du meinst, ist ein sogenanntes "Self-contained executable", d.h.
ein Programm(-paket) bestehend aus einer Datei, welches ohne weitere
Umgebung und ohne Installation auskommt, weil es die Umgebung, sofern
eine existiert, in irgendeiner Form bereits "im Bauch" hat (z.B. durch
statisches Linken bzw. ein intern enthaltenes evtl. komprimiertes
Archiv).
So etwas gibt es meines Wissens nach für OpenOffice.org bislang nicht.
Gruß,
Guido
Ralf Lehmeier
> Könntest du dein Anliegen bitte präzisieren? - Ich habe nicht verstanden,
> worum es dir geht.
>
Um es noch einmal am Mozilla , als Vergleich, festzuachen: Es gibt dort
2 Varianten, einmal mit und einmal ohne Installer. Eine Variante mit
Installer gibt es auch unter Openoffice. Eine ohne habe ich leider noch
nicht gefunden. Genau ein solche suche ich. Unter Mozilla suche ich das
Programverzeichnis lösche oder umbenenne es und kopiere die neuen
Dateien in dieses Programmverzeichnis. Ich benötige hierfür keinen
Installer und brauche auch nicht jedesmal meine Daten neu angeben. Wenn
ich unter Mozilla dies getan habe merkt man höchstens an dem neuen
Startbildschir das etwas neu ist, denn die Anwender arbeiten einfach
weiter - ohne irgendwelche neu Eingaben. Dies wird unter Mozilla mit
sogenannten Binaries (Gepackte ausführbare Versionen)durchgeführt. Genau
so möchte ich gern mein System pflegen - wenn es denn die entsprechenden
Daten gibt.
> Die
> Einstellungen werden wie sonst auch üblich für jeden Benutzer getrennt in
> dessen jeweiligem Bereich verwaltet ($HOME bei UNIX, "Dokumente und
> Einstellungen" bei Windows).
Das wird bei Mozilla auch gemacht, aber eben ohne Nachfragen nach der
Installation.
Bei Umstieg auf eine neuere Version wird einem
> ein Assistent angeboten, der die Einstellungen ggf. importiert.
Leider wurden bei der Umstellung von 1.1.4 auf 2.0.1 auch wieder alle
Daten neu abgefragt. Was ziemlich lästig ist wenn man aktuell bleiben
will und die Mitbenutzer jedesal fragen: " Was will der nun schon wieder
von mir? "
MfG R.Lehmeier
P.S.
Was die Updatefähigkeit angeht so sollte man vielleicht mal über eine
Alternative zur Neuinstallation nachdenken.
Marco Hügel
Eindeutschen kannst Du das ganze über das dt. Sprachpaket.
Marco
Guido Ostkamp
> Wenn es mir beim ersten Vergleich mit Mozilla nicht klar war, wird
> es mir mit dem zweiten nicht klarer.
Da er einen Windows-Newsreader verwendet, nehme ich mal an, er
will dafür auch OpenOffice.org.
Was er meint, ist ein ggf. selbstextrahierendes (ZIP-)Archiv, mit
einer darin befindlichen, nach dem Entpacken ohne weitere Maßnahmen
verwendbaren OpenOffice.org Variante (nach dem Muster von Mozilla,
etwa <http://mozilla.kairo.at/?d=x&i=release&m=d> die "gepackten
ausführbaren Versionen").
Im Prinzip also Portable-OpenOffice.org
<http://portableapps.com/apps/office/suites/portable_openoffice>,
allerdings gibt's dort z.Zt. noch nicht die 2.0.2 und auch das ganze
nur in englischer Sprache.
> Es gibt für OOo bis Version 1.1.5 genau eine Version und zwar eine
> mit Installer und für OOo ab Version 2.0 ebenfalls genau eine und
> zwar ohne Installer.
Hm? Die 2.0 unter Windows läuft auf jeden Fall mit Installer und wird
in einem Nullsoft Installer self-extracting archive geliefert.
>> Was die Updatefähigkeit angeht so sollte man vielleicht mal über
>> eine Alternative zur Neuinstallation nachdenken.
>
> OOo ist updatefähig. Falls du aber nicht Updates, sondern Patches
> meinst: das ist wegen der Linux-Distributionen zur Zeit nicht so
> einfach möglich.
Stimmt nicht so ganz. Ich habe vor ein paar Tagen eine Methode
veröffentlicht, wie man OOo Patches für RPM basierte Linux
Distributionen erstellen und ausliefern könnte, um den Umfang der
Downloads erheblich zu verringern:
<http://www.openoffice.org/issues/show_bug.cgi?id=62893>
Gruß,
Guido
Ralf Lehmeier
> Da er einen Windows-Newsreader verwendet, nehme ich mal an, er
> will dafür auch OpenOffice.org.
Ganau, jedenfalls bis ich mich entschieden habe welches Linux ich
verwenden möchte.
>
> Was er meint, ist ein ggf. selbstextrahierendes (ZIP-)Archiv, mit
> einer darin befindlichen, nach dem Entpacken ohne weitere Maßnahmen
> verwendbaren OpenOffice.org Variante (nach dem Muster von Mozilla,
> etwa <http://mozilla.kairo.at/?d=x&i=release&m=d> die "gepackten
> ausführbaren Versionen").
So sollte es sein - ich habe mich wahrscheinlich nur zu umständlich
ausgedrückt.
>
> Im Prinzip also Portable-OpenOffice.org
> <http://portableapps.com/apps/office/suites/portable_openoffice>,
> allerdings gibt's dort z.Zt. noch nicht die 2.0.2 und auch das ganze
> nur in englischer Sprache.
Kann man den die Dateien des portable Openoffice einfach so ins normale
Openoffice einspielen ( kann ichmir irgendwie nicht so richtig vorstellen ).
Vielleicht gibt es das auch bald auf Deutsch? :-)
MfG aus dem schönen Extertal
R.Lehmeier
Guido Ostkamp
> Kann man den die Dateien des portable Openoffice einfach so ins
> normale Openoffice einspielen ( kann ichmir irgendwie nicht so
> richtig vorstellen ).
Wozu sollte man? Das portable OpenOffice Paket ist komplett, das
"normale" OpenOffice braucht man dann nicht.
Eigentlich ist diese Version für USB-Memorysticks gedacht - zum
Mitnehmen sozusagen - aber von Festplatte geht's natürlich auch.
Oder meintest Du mit Dateien Deine Dokumente? Die kannst Du natürlich
verwenden.
> Vielleicht gibt es das auch bald auf Deutsch? :-)
Bau Dir doch eine deutsche. Eine Anleitung dazu steht bspw. unter
<http://www.911cd.net/forums/lofiversion/index.php/t14607.html> (2.
Beitrag "How to translate Portable 0pen0ffice2 to German").
Gruß,
Guido
Guido Ostkamp
>> Stimmt nicht so ganz. Ich habe vor ein paar Tagen eine Methode
>> veröffentlicht, wie man OOo Patches für RPM basierte Linux
>> Distributionen erstellen und ausliefern könnte, um den Umfang der
>> Downloads erheblich zu verringern:
>
> Prinzip eine Lösung gibt, diese aber nicht soweit standardisiert
> ist, dass sie überall auf Anhieb funktionieren würde.
Meine aktuelle Konzeptstudie erfordert die einmalige Installation
eines kleinen RPM Packages (deltarpm), das man sich problemlos
besorgen kann bzw. selbst compiliert.
In einer endgültigen Lösung wäre es aber auch möglich, das auf
Anwenderseite notwendige Tool 'applydeltarpm' als statisch gelinktes
Programm mitzuliefern, dies würde den Patch-Download nur unwesentlich
um ca. 300 kb vergrößern und dann sofort auf allen Linux-Systemen
funktionieren. Die BSD-Lizenz müßte das IMHO eigentlich erlauben.
Es werden ja nicht die installierten Pakete gepatched, sondern es wird
nur aus einem alten Versions-Download und einem Patch-Download wieder
der neue Original-Download hergestellt. Daher gibt es auch keine
sonstigen Abhängigkeiten.
> Nun, möglicherweise ist es so auch ganz einfach einfacher, was man
> an Bandbreite einsparen würde, würde man an Manpower und Support
> zusätzlich brauchen: welches Paket ist jetzt das richtige, wie
> spiele ich das ein, bei mir funktioniert es nicht... Und herstellen
> müsste die ? ja auch jemand.
Herstellen müßte sie jemand, aber so etwas wäre ja völlig
automatisierbar. Horrenden Supportaufwand sehe ich nicht, meine Tools
bringen ein README_FIRST.txt in das tarball mit genauer Beschreibung,
was zu tun ist und auch das aufzurufene Skript ist ziemlich
narrensicher und gibt ggf. entsprechende Hinweise.
Vgl. mit der manuellen Prozedur zum Einspielen von RPM Packages, die
ja auch jetzt schon notwendig ist, halte ich das für relativ trivial.
Die Einsparung an Zeit und Bandbreite ist jedenfalls enorm, besonders
bei Entwicklerversionen mit geringem Hub, da werden teilweise bis zu
99% eingespart und von einem 140 MB Download bleibt nur noch 1 MB
übrig.
Mag aber sein, daß auf Projektseite das Interesse z.Zt. gering ist und
zwingen kann ich niemand. Die Resonanz war jedenfalls bislang leider
gleich Null.
Gruß,
Guido
Hajo Schepker
> Hallo,
>
> Am Freitag, 10. März 2006 00:22 schrieb Ralf Lehmeier:
>>> Könntest du dein Anliegen bitte präzisieren? - Ich habe nicht verstanden,
>>> worum es dir geht.
>>>
>> Um es noch einmal am Mozilla , als Vergleich, festzuachen: Es gibt dort
>
> mit dem zweiten nicht klarer.
OO-Programmverzeichnis kopieren kann.
>
>> 2 Varianten, einmal mit und einmal ohne Installer. Eine Variante mit
>> Installer gibt es auch unter Openoffice. Eine ohne habe ich leider noch
>> nicht gefunden. Genau ein solche suche ich. Unter Mozilla suche ich das
>
> Installer und für OOo ab Version 2.0 ebenfalls genau eine und zwar ohne
> Installer.
>
>> Dateien in dieses Programmverzeichnis. Ich benötige hierfür keinen
>> Installer und brauche auch nicht jedesmal meine Daten neu angeben. Wenn
>
> Windows kannst du den Setup mit dem Parameter /a starten, dabei wird nichts
> in die Registry geschrieben, nur entpackt. Unter Linux benutzt du einfach
> den Installer deiner Wahl, RPM, DEB oder relocalisierst es oder du packst
> es um oder wie auch immer.
>
>> Was die Updatefähigkeit angeht so sollte man vielleicht mal über eine
>> Alternative zur Neuinstallation nachdenken.
>
> das ist wegen der Linux-Distributionen zur Zeit nicht so einfach möglich.
>
> OOo, Betriebssystem usw. Sonst kann dir niemand helfen.
>
> Beste Grüße
--
Mit freundlichen Grüssen
Hajo S. Schepker - www.schepker.de - sche...@schepker.de
Mitglied im Team Staroffice e.V. - www.teamstaroffice.de
Gesendet mit Mozilla-Thunderbird unter Fedora Core 4 + KDE Desktop
Guido Ostkamp
> D.h. man müsste die RPM der Vorversion aufbewahren?
Ja, präziser gesagt muß man genau das Tarball aufbewahren, welches man
heruntergeladen hatte, also z.B.
"OOo_2.0.1_LinuxIntel_install_de.tar.gz"
> Könnte man auf ein durch ein Delta erzeugtes RPM (2. Generation)
> eigentlich wieder ein Delta anwenden (3. Generation), oder geht das
> nur ein Mal?
Die entstehende Fassung ist bis auf zwei zusätzliche Files (ein README
und das patch_Script) zu 100% binär identisch zur Originalversion
(also insbesondere gilt das für die RPMs). Wenn man sie wieder
verpackt (tarball erstellen), kann man darauf natürlich dann den
nächsten Patch wieder anwenden, um weiterzukommen.
> Naja, 'rpm -U' ist nicht besonders aufwendig und es ist ja teilweise
> auch in irgendwelche (GUI-)Frontends eingebaut. Deltas wären also
> eher etwas für den erfahrenen Anwender.
Pfft. Um 'rpm' von Hand anwerfen zu können, braucht es schon einen
erfahrenen Anwender (die anderen verwendet sowieso YaST u.ä.). DAU's
haben ja vorher erstmal ein tarball zu extrahieren (wie schrecklich)
und außerdem befinden sich die RPMs auch noch in verschiedenen
Unterdirectories (grusel). Und dann erst die notwendigen RPM Optionen
(gar nicht auszudenken) ... LOL ;-)
Mein Patch braucht nur ein
$ ./patch_ooo <somepath>/OOo_2.0.1_LinuxIntel_install_de.tar.gz
zusätzlich. Ich sehe da kein Problem.
> Das ist wohl richtig, aber dienen die Snapshots nicht auch dazu, das
> Verhalten beim Kompilieren und der Installation zu testen? Dann wäre
> ausgerechnet da, wo man das größte Einsparpotential hätte, der
> geringste Bedarf.
Snapshots sind die gleichen fertigen Installationssätze wie normale
Releases. Mit Compilierung hat das rein gar nichts zu tun. Und die
Installation erfolgt ja auch nach Nutzung des Patch-Mechanismus ganz
normal, da gibt es keinen Unterschied - wie gesagt, daß Ergebnis ist
binär identisch zum Original.
> Die Anwender fragen immer wieder danach, deshalb erkenne ich von
> deren Seite durchaus Interesse. Oder sind es nur /bestimmte/
> Anwender, die hierfür Bedarf haben, und den anderen ist es nicht so
> wichtig, Hauptsache, es lässt sich problemlos installieren und -
> noch wichtiger - problemlos damit arbeiten?
Leute von 1-2 GB DSL Volumenbegrenzung bzw. schlimmer noch
Modem-Zugang würden vielleicht eher zu Patches neigen, falls sie sich
nicht auf offizielle Releases auf Zeitschriften-CDs beschränken.
Gruß,
Guido
Marc 'BlackJack' Rintsch
>> Bei Umstieg auf eine neuere Version wird einem
>> ein Assistent angeboten, der die Einstellungen ggf. importiert.
>
> Leider wurden bei der Umstellung von 1.1.4 auf 2.0.1 auch wieder alle
> Daten neu abgefragt. Was ziemlich lästig ist wenn man aktuell bleiben
> will und die Mitbenutzer jedesal fragen: " Was will der nun schon wieder
> von mir? "
Bei einer Umstellung mit so einem grossen Versionssprung würde ich immer
erwarten, das sich in den Konfigurationsdaten Veränderungen ergeben
können was das Format oder die Verzeichnisanordnung angeht.
Eine "Neuinstallation" mit dem Angebot die alten Konfigurationsdaten zu
übernehmen und dabei dann eventuell in ein neues Format zu konvertieren
ist doch gar nicht so schlecht.
Dabei sollten dann natürlich keine Daten vom Benutzer abgefragt werden,
die er schonmal angegeben hat. Wenn das bei kleineren Versionssprüngen
auch zwingend passiert, dann solltest Du ein Ticket dafür aufmachen.
Ciao,
Marc 'BlackJack' Rintsch
Guido Ostkamp
> Siehst du, und den hätte ich z.B. gar nicht mehr, nach 'gunzip'.
LOL - damit hast Du Dich gerade in die Newbie-Klasse einsortiert ;-)
Warum sollte man gunzip manuell aufrufen? Sowas macht man doch gleich
per "tar xvzf", dabei wird das gzipped-tarball erst gar nicht
modifiziert.
> Natürlich könnte ich es danach wieder neu packen, aber selbst wenn
> ich zufällig die selbe Kompressionsstufe erwische, wer sagt mir,
> dass das bitidentisch ist? Ich müsste also zuerst den Tarball
> kopieren und irgendwo speichern.
Wer hat gesagt, daß ein gzipped-tarball bitidentisch sein muß und wozu
überhaupt? Nur die RPM's innerhalb des tarballs müssen die gleichen
bleiben, damit mein Patch noch geht. Ob da normal oder mit -9
ge-gezipped ist, ist egal.
> Und die Benutzer, für die ein kleinerer Download von Bedeutung wäre,
> kommen vielleicht mit einem Patch zurecht.
Hier fehlt wohl nach Deiner Logik ein 'nicht', nehme ich mal an.
Ich denke, daß Linux User in der Regel mehr Ahnung von Ihrer Kiste
haben als Windows User. Und falls nicht: Wer nicht lernresistent ist,
hat eben Pech gehabt.
> Das ist mir schon klar, aber ich habe mich wohl missverständlich
> ausgedrückt. Ich meinte, dass Snapshots ja nicht für Anwender,
> sondern nur zum Testen hergestellt werden. Sie richten sich an einen
> vergleichsweise sehr kleinen Kreis, sodass dort der Nutzen in einem
> schlechten Verhältnis zum Aufwand stehen würde.
Der Aufwand ist fast gleich Null, wenige Minuten zur Herstellung eines
Patch Tarballs und Upload desselben. In der Regel gibt es einen Build
pro Woche.
> Im Moment scheitert es wohl sowieso an mangelndem Plattenplatz...
Du meinst, das OOo Projekt hat zuwenig Platz auf ihren FTP-Servern.
Ja, das scheint so zu sein. Wenn sie auch wirklich auf jedem Server
die gesamte Palette mit allen Sprachen und dann noch verschiedene
Versionen unterbringen wollen, ist halt irgendwann Schluß.
Das Problem ist, daß man für jede Ländervariante wieder das komplette
Ding bereithält (> 100 MB), obwohl es eigentlich mit der englischen
Variante und einem language-Pack getan wäre.
Gruß,
Guido
Guido Ostkamp
> Und falls nicht: Wer nicht lernresistent ist, hat eben Pech gehabt.
Jetzt passiert mir das auch schon - Korrektur:
Wer lernresistent ist, hat eben Pech gehabt.
Gruß,
Guido
Dirk Weber
> Pfft. Um 'rpm' von Hand anwerfen zu können, braucht es schon einen
> erfahrenen Anwender (die anderen verwendet sowieso YaST u.ä.).
> DAU's haben ja vorher erstmal ein tarball zu extrahieren (wie
> schrecklich) und außerdem befinden sich die RPMs auch noch in
> verschiedenen Unterdirectories (grusel). Und dann erst die
> notwendigen RPM Optionen (gar nicht auszudenken) ... LOL ;-)
Was soll dieses Lustigmachen über Durchschnittlich Ausgebildete User?
Wer sich endlich dazu durchgerungen hat, sich statt dieser weit
verbreiteten Emulation ein Betriebssystem zuzulegen, dem sei es
durchaus verziehen, wenn er deswegen noch lange nicht zum Experten in
IT-Fragen werden möchte, sondern einfach User bleiben möchte.
Und da stellt es für viele immer noch ein subjektives Problem dar,
einen tarball zu extrahieren (auch wenn es z. B. mittels Konqueror
absolut simpel ist, aber wer glaubt das schon, wenn er es nicht vorher
ausprobiert hat?).
Diese Leutchen wären für eine Oberfläche dankbar, auf der sie mittels
der Maus-Kontexttaste für einen tarball eine Option "Installieren"
auswählen könnten. Ich kann das durchaus nachvollziehen.
> Leute von 1-2 GB DSL Volumenbegrenzung bzw. schlimmer noch
> Modem-Zugang würden vielleicht eher zu Patches neigen, falls sie
> sich nicht auf offizielle Releases auf Zeitschriften-CDs
> beschränken.
Nicht zuletzt gibt es Leute, die z. B. OpenOffice.org produktiv
einsetzen, obwohl das Weltunternehmen Telekom sich nicht in der Lage
sieht, die BRD flächendeckend mit DSL zu versorgen. Der Download per
ISDN hat hier heute etwas über vier Stunden gedauert - und bei ISDN
gibt es nun mal keine Flatrate.
Gruß aus Arft,
Dirk Weber
Martin Reising
> Am Sonntag, 12. März 2006 23:20 schrieb Guido Ostkamp:
> Ich weiß, dass es sie in GNU tar gibt, aber du kannst dich gerne auf
> http://www.freebsd.org/cgi/man.cgi selbst davon überzeugen, dass es sie
> eben nicht überall gibt.
Who cares. Dafür hat man ja die UNIX-Toolbox und benutzt eben einfach
gzip -cd <TGZ> | tar -cvf -
GNU tar mach(te) auch nichts anderes.
> Und überhaupt: Warum sollte man ein TAR-Archiv von RPM-Dateien gzip
> komprimieren? RPM-Dateien sind doch schon bzip2 komprimiert, eine weitere
> Komprimierung bringt also nichts oder vergrößert das Archiv sogar.
Andersherum wird ein Schuh draus. RPM ist mit gzip komprimiertes cpio
plus Header.
http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/swinstall.html
Im Gegensatz zu tar.gz könnte tar.bz2 das verkleinern. Allerdings
würden mich Verkleinerungen der Dateigröße um mehr als 5% überraschen.
> Hast du nicht gesagt, dass man das Delta auf das TGZ-Archiv anwenden würde?
Hat er nicht. Nur das create_ooo_patch.pl von
http://www.openoffice.org/issues/show_bug.cgi?id=62893
deltarpm benötigt.
> Also gehe ich davon aus, dass man zusätzlich ein Skript bräuchte, das erst
> das Archiv entpackt und dann auf die entpackten RPM die Deltas anwenden
> würde. Wenn man aber ein Skript dazupacken würde, hätte man das Archiv ja
> schon entpackt, um das Skript ausführen zu können, und bräuchte also kein
> Skript mehr, das das Archiv entpackt.
Wenn create_ooo_patch.pl, das dann besser patch-ooo heißt und ein
Softlink auf create_ooo_patch.pl ist, in openoffice.org-base
integriert ist dein konstruierter Knoten zerschlagen.
So lange das nicht der Fall ist spricht ja nichts dagegen sich das
Perlscript aus dem Issue zu kopieren und zu benutzen.
--
Nicht Absicht unterstellen, wenn auch Dummheit ausreicht!
Guido Ostkamp
> Nanana. Zu meiner Zeit, als ich die Manualpage von tar auswendig
> gelernt habe, gab es die Option (genaugenommen ein "Key", nicht eine
> Option) 'z' nicht. Und auf manchem richtigen UNIX gibt es sie auch
> heute noch nicht.
Wir reden hier über OpenOffice.org auf Linux und nicht über FreeBSD
(keine Ahnung, was für ein Packageformat die verwenden). Zeig mir eine
eingermaßen aktuelle Linux Distribution, die keinen GNU tar mitbringt.
Unabhängig davon ist es natürlich richtig, daß andere Unix Varianten
wie Solaris etc. einen "tar" haben, der diese Option nicht beherrscht.
Aber dann würde ein Profi immer noch "gzip -d -c file.tar.gz | tar xvf
- " verwenden, oder besser sich GNU tar sofort dahin portieren -
schließlich braucht man ein vernünftiges Environment ;-)
> Und überhaupt: Warum sollte man ein TAR-Archiv von RPM-Dateien gzip
> komprimieren? RPM-Dateien sind doch schon bzip2 komprimiert, eine
> weitere Komprimierung bringt also nichts oder vergrößert das Archiv
> sogar.
Ist nicht meine Idee, die Dinger werden nunmal so ausgeliefert, es
spart nicht viel, aber ein klein wenig. Ich halte mich nur dran, und
fordere vom Nutzer keinerlei Änderung außer das er archiviert, was er
bekam - it's that easy.
> Hast du nicht gesagt, dass man das Delta auf das TGZ-Archiv anwenden
> würde?
Mein im Patch-tarball mitgeliefertes Skript entpackt das Original-TGZ
und wendet auf die dort drin enthaltenen RPMs dann die einzelnen
Patche an. Hinterher hast Du quasi die neue Original-Vollversion und
kannst sie wie gewöhnlich installieren und auch archivieren.
> Also gehe ich davon aus, dass man zusätzlich ein Skript bräuchte,
> das erst das Archiv entpackt und dann auf die entpackten RPM die
> Deltas anwenden würde. Wenn man aber ein Skript dazupacken würde,
> hätte man das Archiv ja schon entpackt, um das Skript ausführen zu
> können, und bräuchte also kein Skript mehr, das das Archiv entpackt.
> -v, please.
Du entpackst nur das Patch-Tarball selbst von Hand, aber nicht die
alte Version, auf die der Patch angewandt wird, denn das macht das
Skript. Du hast also nicht wesentlich mehr Aufwand als bei der
Vollversion, denn auch da mußt Du das initiale 'tar' zum Entpacken
selbst machen.
Gruß,
Guido
Guido Ostkamp
> Und da stellt es für viele immer noch ein subjektives Problem dar,
Wenn Du meinst. Den selbstextrahierenden grafischen Installer mit
lokaler Sprachunterstützung und Onlinehilfe kannst ja dann gerne Du
beisteuern, ich habe jedenfalls mit meiner Freizeit was anderes vor.
Gruß,
Guido