Thorsten Strusch wrote:

Hi Leute,

ich möchte einige Pakete, die ich immer wieder installiere verändern und anschließend auf eine angepaßte Installations CD brennen. Die meisten habe ich nur als rpm und nicht als src.rpm - letzere kann ich ohne große Arbeiten anpassen und neu zu einem rpm compilieren.

Da ich zu Hause aber nur ein 56K modem habe (bitte keine Witze darüber!) möchte ich nicht immer das entsprechende src.rpm ziehen, sondern suche eine Möglichkeit ein bestehendes rpm wieder in ein src.rpm zu wandeln. Oder wenigstens einige Dateien darin bearbeiten.

Bin ich zu blauäugig, oder ist das möglich?

Radio Eriwan antwortet: " Ja und nein in beiden Fällen." 1.1 wenn du aus den Programm-Binarys wieder die Sourcen machen willst. 1.2 wenn es nur um nicht Programm-Binarys geht. 2.1 siehe 1.2 2.2 siehe 1.1, es geht zwar ist aber viel zu Aufwendig Stichworte: deassemblieren, decompilieren.

Die man-page zu rpm gibt _mir_ leider keine Hilfe.

Sie ist ja auch nicht gerade ausführlich. Und zum Erstellen von RPM-Paketen wird nur etwas über die Parameter gesagt. Ich benutze so ein System zum Übertragen von Programmen und Konfigurationen vom Test- auf den Produktions-PC und zu den Kunden. Etwas Hintergrund: RPM macht im Grunde nichts anderes wie z.B. tar es packt eine Liste von Dateien zu einer zusammen. Dazu wird das %files-Script aus dem SPEC-File benutzt. Den SPEC-File benutzt du zu Steuern der Erstellung des RPM-Paketes, bei der Installation spielt er dann keine Rolle mehr. Bei der Installation unterscheidet sich RPM dann aber sehr stark von tar, erlegt eine Datenbank an bzw fügt in einer vorhandenen etwas ein, nämlich einmal die Dateien die es Ausgepackt hat und TAGs die im SPEC-File gesetzt worden sind ( z.B Name, Version etc.). Bei der Installation passiert zwar noch einiges mehr mit der Datenbank, dazu komme ich später. Zurück zum SPEC-File: er enthält neben besagtem %files-Script (nur Dateien die dort stehen werden gepackt) auch Makros, Scripte und die schon erwähnten TAGs für die Datenbank und zum Erstellen des Source-RPMs. Wenden wir uns zuerst den Scripten zu: RPM kennt 4 Arten von Scripte - build-scripte: sie werden ausgeführt beim Erstellen des Packets, als da wären %prep,%build, %install (nicht von dem Namen täuschen lassen). Mit ihnen läßt sich steuern was vor dem packen alles erledigt werden muß. Mit dem Parameter -[b|t][p|c|i] steuert man bis wohin RPM die Scripte abarbeiten soll. Sie sehen in SPEC-Files zwar immer sehr wüst aus, sind aber nichts anderes wie shell-scripte. - install/erase-scripte: sie werden bei der De/Installation des binary-RPMs ausgeführt. Da haben wir: - %pre, es wird vor der Installation ausgeführt (Dateien aus dem Packet sind noch nicht installiert) ACHTUNG: TIPFEHLERGEFAHR mit %prep ( aus Erfahrung) - %post, es wir nach der Installation ausgeführt, es kann also auf Dateien aus dem binary-RPM zugegriffen werden Beispiel: SuSe fügt damit Daten an die rc.config an - %preun, es wird vor der Deinstallation ausgeführt (Dateien aus dem Packet sind noch installiert) - %postun, es wird nach der Deinstallation ausgeführt (Dateien aus dem Packet sind nicht mehr vorhanden) - trigger-scripte: sie werden ausgeführt, wenn andere vorher benannte RPM-Packete installiert/deinstalliert werden. Auch hier haben wir wieder 4 Stück: - %trigger, es wird vor der Installation des anderen Packets ausgeführt - %triggerin, es wird nach der Installation des anderen Packets ausgeführt - %triggerun, es wird vor der Deinstallation des anderen Packets ausgeführt - %triggerpostun, es wird nach der Destallation des anderen Packets ausgeführt - verifycation-script: es wird bei dem Befehl rpm -V|--verify ausgeführt und heißt %verifyscript Noch ein Wort zur Scriptsprache: Soviel ich verstanden habe kann jede Script/Interpretersprache verwendet werden, der Interpreter muß nur vorhanden sein. Voreingestellt ist die sh. Bei den Installations-, trigger-scripten und dem verifictions-script übergibt man den Interpreter mittels eines Parameters, der Interpreter muß natürlich auf dem Zielsystem installiert sein. Bei den build-scripten muß man irgendwo eine RPM-Umgebungsvariable ändern, aber Achtung plötzlich funktionieren dann die Macros nicht mehr. Kommen wir nun zu den Makros. Sie werden in den build-scripten ausgeführt, ob Makros auch in den anderen Scripten benutzt werden können, weiß ich nicht, wenn sie vor dem Einbinden in das Binary-RPM expandiert werden dann ja, wenn sie erst beim ausführen expandiert sollte man es nicht, und wenn sie garnicht expandiert werden kann man es nicht. Man kann Makros auch selber schreiben, das führt hier aber zu weit, aber es gibt auch jede Menge vordefinierte. Auf 4 die ich selber viel benutze und für sehr nützlich halte, gehe ich hier ein, da sie viele Fehler vermeiden helfen. - %setup, es wird im %prep-script verwendet, es löscht vorhandene alte Sourcen, packt uns die Sourcen aus und wechselt in das Verzeichnis. Wichtig ist hier der Parameter -n <Name> er gibt den Namen an unter dem im BUILD-Verzeichnis die Sourcen zu finden sind und in das gewechselt wird. Hat man mehrere Sourcen, sind folgende beiden Parameter noch wichtig -b#, erst entpacken dann wechseln, -a#, erst wechseln dann entpacken. # steht für die Nummer des Source-Tags, Source-Tags werden wie folgt angelegt: Source: <erste Source> entspricht #= 0 Source1: <zweite Source> entspricht #= 1 ... Source[n]: <n-te Source> entspricht #= n - %patch, es patcht uns die entpackten Sourcen, mehrere Patche werden wie folgt angegeben %patch3 oder %patch -P 3 für das 3, Patch-Tag. Der Parameter -p wird wie beim normalen patchen verwendet. TAGs werden wie bei den Sourcen angelegt. - %configure, es setzt und exportiert Umgebungsvariablen und führt configure mit einer Reihe von Parametern aus. Es sind Standard Parameter und Umgebungsvariablen, die entweder vorgegeben sind oder durch TAGs im SPEC-File angegeben wurden, z.B. BuildRoot oder die System-Architektur. - %makeinstall, hier wird ein "make install" mit Parametern ausgeführt. Wer sich mit Shell-scripten auskennt und selber Makros schreiben will oder wissen will wass genau bei den Makros ausgeführt wird, sollte einen Blick in lib/rpm/macros riskieren. Soviel zum Hintergrund von RPM, es ist vieleicht etwas viel und erschlägt einen beim ersten Lesen, aber es ist wichtig um zu wissen was geht und was nicht geht. Die Frage war ja: Ich habe ein Binary-RPM kann ich daraus ein Source-RPM machen, weil, ich habe Skripte oder die Konfigurationsdateien geändert und will die nun auf einen anderen PC mit den Änderungen installieren. Also ein Richtiges Source-RPM mit Sourcen der Programme, die du patchen kannst kriegst du nicht mehr hin :-(, aber ein Binary-RPM, mit allen Änderungen die du gemacht hast :-). Es gibt dafür wieder mehrere Wege, ich zeig dir hier einen an dem Beispiel bind, ich habe es ausgesucht, weil es auch praktischen Wert hat so ein Binary-RPM zu haben, das komplette Installieren eines DNS-Servers inclusive Konfiguration mit einem Befehl nachdem der eigentliche Rechner streikt. rpm -ihv bind-meine-conf.rpm und schon habe ich einen neuen Nameserver im Netz, jetzt nur noch die IP-Adresse ändern, und Namen können wieder aufgelöst werden. Vorausgesetzt auf dem neuen Rechner gibt es kein Abhängigkeitsproblem und bind war darauf noch nicht installiert. Voraussetzung für die Erstellung des Binary-RPMs: Das Paket ist auf dem Rechner als RPM installiert, du hast alle Änderungen an den Dateien gemacht und das Programm ist lauffähig installiert (bei bind z.B sind die ZONE-Dateien vorhanden). Du befindest dich als root im /usr/src/packages/SPEC-Verzeichnis. Als erste müssen wir die SPEC-Datei erstellen, fast alle Informationen bekommen wir aus der RPM-Datenbank :-). Als erstes müssen wir die TAGs festlegen, rpm -qi bind8 gibt uns hier die nötigen Infos. Alle Infos werden hier nicht benötigt, die benötigten zähle ich hier auf, die Werte stehen hinter dem ":" <-- SPEC --> Name: Version: Release: Group: License: Packager: <dein Name> Summary: %{name} - Nameserver fertig konfiguriert <-- SPEC --> Wo nichts steht, die Ergebnisse der Abfrage eintragen, die Reihenfolge ist beliebig bis auf das Summary-TAG, das muß nach dem Name-TAG stehen, da es auf den Wert dieses TAGs zugreift. Das Description-TAG ist ein besonderes TAG. Es heißt: <-- SPEC --> %description <-- SPEC --> Es endet nicht mit einem ":" sondern mit <LF> und gilt bis zum ersten Script. Ein rpm -q --scripts bind8 zeigt uns die De/Installations-Scripte, es sind folgende: %pre, begint mit "preinstall script (through /bin/sh):" %post, begint mit "postinstall script (through /bin/sh):" %postun, begint mit "postuninstall script (through /bin/sh):" Das %pre-script brauchen wir nicht, es ist nur ein Hinweis der uns nicht mehr betrifft. Im SPEC-File müssen wir folgende eintragen: <-- SPEC --> %post echo "Updating etc/rc.config..." ... bis ... sbin/insserv etc/init.d/named %postun sbin/insserv etc/init.d/ <-- SPEC --> Jetzt beibt nur noch das %files-script. RPM kennt 3 Arten von Dateien: Dokumentation, Konfiguration und den Rest. Fangen wir mit den Dokumenten an. Der Eintrag sieht so aus: %doc /Pfad/Dateiname . Pfade und Name bekommen wir mit rpm -qd bind8. Für jede Datei eine Zeile mit Eintrag. <-- SPEC --> %files %doc ... %doc ... <-- SPEC --> Jetzt die Konfigurationsdateien, der Eintrag sieht so aus: %config /Pfad/Dateiname . Pfade und Name bekommen wir mit rpm -qc bind8. Für jede Datei eine Zeile mit Eintrag. Eine Datei bekommt einen besonderen Eintrag. Dies ist notwendig, weil Konfigurationsdateien nicht einfach überschrieben werden, sondern sie werden als *.rpmsave gesichert. Das heißt aber auch, diese Dateien werden bei der Deinstallation nicht gelöscht, das ist normalerweise auch so gewünscht, nur die eine Datei muß gelöscht werden, da sonst das %postun nicht funktioniert. <-- SPEC --> %config(missingok) /etc/init.d/named %config ... ... <-- SPEC --> Nun folgt der Rest der Dateien, der Eintrag sieht so aus: /Pfad/Dateiname. Pfade und Name bekommen wir mit rpm -ql bind8. Nur die Dateien, die wir schon eingetragen haben lassen wir aus. Für jede Datei eine Zeile mit Eintrag. <-- SPEC --> /... /... ...usw /... <-- SPEC --> Jetzt müssen wir nur noch dafür sorgen, das auch unsere ZONE-Dateien mitgepackt werden. Da meine ZONE-Dateien alle auf .zone enden, ist das relativ einfach. <-- SPEC --> %config /var/named/*.zone <-- SPEC --> Im %files-script wird auch expandiert und zwar auf zwei Arten, einmal Verzeichnise, d. h. der Eintrag ist ein Verzeichnis, wird das ganze Verzeichnis mitgepackt auch Unterverzeichnisse. Und einmal ganz Normal mit Wildcards. Das bringt uns aber auch ein Problem, denn RPM mag es garnicht, wenn eine Datei mehrmals vorkommt. Darum müssen wir nun die Verzeichnis Einträge oder die einzelnen, mehrfach Dateien entfernen. Bei den Dokumenten- und normalen Dateien entferne ich meistens die Verzeichnisse, bei Konfigurationsdateien die einzelnen Dateien. Jetzt prüfen wir die SPEC-Datei mit rpm -bl <SPEC-Datei>. Wenn kein Fehler erscheint, meistens sind es Tipfehler oder doppelte Dateieinträge, können wir das Packet bauen. Jetzt erscheint, wenn er das Packet gepackt hat, folgendes auf dem Bildschirm: <-- Terminal --> Requires: /bin/sh ld-linux.so.2 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.2) Wrote: /usr/src/packages/SRPMS/bind8-8.2.3-92.src.rpm Wrote: /usr/src/packages/RPMS/i386/bind8-8.2.3-92.i386.rpm <-- Terminal --> Ooops, da hat er ja doch ein Source-RPM geschrieben. Ja, darin befindet sich aber nur die SPEC-Datei, nur mit dem SOurce-RPM kann man nicht viel anfangen, es sei den man baut das gerade entstandene Binary-RPM dort als Source ein. Das Binary-RPM kann ich nun wie ein normales Binary-RPM installieren. Vorausgesetzt das System auf dem es installiert werden soll erfüllt die Abhängigkeiten, s. o. Requires:... und die Verzeichnisstrucktur ist entsprechend. HTH cu Gerald PS: Ja, ich weiß die Mail ist extrem lang, darum 3 Bitten: 1. bleibt bitte im Thread, 2. bitte kein TOFU oder Fullquote, wenn 1. beachtet wird reichen 2-5 Zeilen davor gequotet; und 3. bitte keinen Thread der sich damit beschäftigt ob so lange Mails sein müssen oder nicht, manchmal lassen sich Probleme leider nicht anders lösen.