Hallo!
Ich habe mich die letzten Wochen mit rpmbuild, also dem erstellen von rpm beschäftigt. Was mir das Leben einfacher gemacht hätte, wäre ein ein kommentiertes Minimalbeispiel. Um es dem Nächsten leichter zu machen, wollte ich ein Kurzen Artikel mit einem quasi "Hallo-Welt-rpmbuild" schrieben.
Jetzt überlege ich, ob das Fedora-Wiki der richtige Platz dafür ist, und wenn 'ja', wo?
Pro: Fedora ist RPM-Basiert. Kontra: rpm ist nicht "Fedora-Only"
...Meinungen?
Gruß
Olaf
On 02/25/2012 10:34 AM, Olaf Radicke wrote:
Ich habe mich die letzten Wochen mit rpmbuild, also dem erstellen von rpm beschäftigt. Was mir das Leben einfacher gemacht hätte, wäre ein ein kommentiertes Minimalbeispiel. Um es dem Nächsten leichter zu machen, wollte ich ein Kurzen Artikel mit einem quasi "Hallo-Welt-rpmbuild" schrieben.
So wie das? https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package oder umfassend https://fedoraproject.org/wiki/How_to_create_an_RPM_package
Jetzt überlege ich, ob das Fedora-Wiki der richtige Platz dafür ist, und wenn 'ja', wo?
Das Wiki ist für alle Art von Dokumentation der richtige Platz ;-)
Gruss Fabian
Hi!
Langsam entwickele ich einen richtigen inbrünstigen Hass auf rpm/rpmbuild.
Wenn ihr euch mal mein Beispiel anseht: https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package/de#Make...
Dann fällt euch vielleicht im Makefile diese Zeile auf...
<snip> dist-rpm: pre-rpm <snap>
Eigentlich ist das "pre-rpm" zu viel, denn es sollte vom Speck-File aufgerufen werden...
<snip> %prep %setup -q make PREFIX=$RPM_BUILD_ROOT pre-rpm <snap>
Doch dieser Befehl wird nie ausgeführt. Ich habe nie wirklich verstanden was "%setup -q", aber offenbar führt er dazu, das "%prep" nicht ausgeführt wird. Wenn ich "%setup -q" woanders hin verschiebe, wird "%prep" auf ein mal ausgeführt:
<snip> [...] + cd /home/or/rpmbuild/BUILD + make PREFIX=/home/or/rpmbuild/BUILDROOT/rpm-uebung-1-1.noarch pre-rpm make[1]: Entering directory `/home/or/rpmbuild/BUILD' make[1]: *** Keine Regel, um >>pre-rpm<< zu erstellen. Schluss. [...]
<snap>
Der prefix ist definitiv falsch. Also ersetze ich die Zeile durch...
<snip> make PREFIX=%(echo $HOME)/rpmbuild/ pre-rpm <snap>
Nun lautet die Fehlermeldung....
<snip> [...] Ausführung(%prep): /bin/sh -e /var/tmp/rpm-tmp.N9C8lB + umask 022 + cd /home/or/rpmbuild/BUILD + make PREFIX=/home/or/rpmbuild/ pre-rpm make[1]: Entering directory `/home/or/rpmbuild/BUILD' make[1]: *** Keine Regel, um >>pre-rpm<< zu erstellen. Schluss. [...] <snap>
...Ja? Warum sollte jetzt das Makefile auf ein mal in /home/or/rpmbuild/BUILD sein? Irgend wie scheint sich auf ein mal rpmbuild nicht mehr zuständig zu fühlen, das Tar-Archif dort hin auszupacken, wo es es gerne hin haben will...
Also wenn ich das richtig sehe, gibt es hier ein Henne-Ei-Problem (http://de.wikipedia.org/wiki/Henne-Ei-Problem):
Das Makefile brauch Informationen von rpmbuild mit es die nötigen Vorbereitungen treffen kann, mit rpmbuild funktioniert. rpmbuild braucht wiederum wiederum Informationen von Makefile.
Jetzt könnte man es sich leicht machen und ein autonomes Spec-File machen. Bei einem Projekt mit einer Bash-Datei kein Problem. Aber bei einem Großen Projekt mit hunderten Dateien wird man ja schier wahnsinnig ständig zwei Files anpassen zu müssen. Zumal 95% identisch und redundant ist.
Also entweder ich hab irgend was Grundsätzliches an rpmbuild noch nicht verstanden, oder das Tool ist echt für den Ar***.
Gruß
Olaf
On Thu, 1 Mar 2012 22:34:24 +0100 (CET), OR (Olaf) wrote:
Hi!
Langsam entwickele ich einen richtigen inbrünstigen Hass auf rpm/rpmbuild.
Keine gute Einleitung. ;) Bin kurz angebunden, daher nur ein paar Kommentare im folgenden:
Wenn ihr euch mal mein Beispiel anseht: https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package/de#Make...
Dann fällt euch vielleicht im Makefile diese Zeile auf...
Ich verstehe den Ansatz mit dem Makefile, die Implementation ist aber noch Murks.
<snip> dist-rpm: pre-rpm <snap>
Eigentlich ist das "pre-rpm" zu viel, denn es sollte vom Speck-File aufgerufen werden...
Sicherlich kein Tippfehler, also lassen wir es doch bei "spec", okay?
<snip> %prep %setup -q make PREFIX=$RPM_BUILD_ROOT pre-rpm <snap>
Doch dieser Befehl wird nie ausgeführt. Ich habe nie wirklich verstanden was "%setup -q",
Im Gegensatz zu %prep ist %setup ein Kommando mit hinreichend gut dokumentierten Optionen. Laß für den Anfang -q ("quiet") weg, damit in der Ausgabe nichts unterdrückt wird. %setup ist für das Anlegen des "Build" Verzeichnisses und das Entpacken der "Source" Archive zuständig.
aber offenbar führt er dazu, das "%prep" nicht ausgeführt wird. Wenn ich "%setup -q" woanders hin verschiebe, wird "%prep" auf ein mal ausgeführt:
<snip> [...] + cd /home/or/rpmbuild/BUILD + make PREFIX=/home/or/rpmbuild/BUILDROOT/rpm-uebung-1-1.noarch pre-rpm make[1]: Entering directory `/home/or/rpmbuild/BUILD' make[1]: *** Keine Regel, um >>pre-rpm<< zu erstellen. Schluss. [...]
<snap>
Der prefix ist definitiv falsch. Also ersetze ich die Zeile durch...
<snip> make PREFIX=%(echo $HOME)/rpmbuild/ pre-rpm <snap>
Dieser PREFIX ist auch falsch. Ohne Kommentierung sogar unsinnig. Üblich wäre PREFIX=/usr bzw. PREFIX=%{_prefix}.
Nun lautet die Fehlermeldung....
<snip> [...] Ausführung(%prep): /bin/sh -e /var/tmp/rpm-tmp.N9C8lB + umask 022 + cd /home/or/rpmbuild/BUILD + make PREFIX=/home/or/rpmbuild/ pre-rpm make[1]: Entering directory `/home/or/rpmbuild/BUILD' make[1]: *** Keine Regel, um >>pre-rpm<< zu erstellen. Schluss. [...] <snap>
...Ja? Warum sollte jetzt das Makefile auf ein mal in /home/or/rpmbuild/BUILD sein? Irgend wie scheint sich auf ein mal rpmbuild nicht mehr zuständig zu fühlen, das Tar-Archif dort hin auszupacken, wo es es gerne hin haben will...
rpmbuild erwartet eine bestimmte Verzeichnisstruktur, in dessen Verzeichnissen die einzelnen Dateien gesucht werden. Befindet sich die spec Datei in $PWD, werden die "Source" Dateien/Archive dort noch lange nicht gesucht. Schau Dir als Beispiel mal die Ausgabe von
rpm --eval %_topdir rpm --eval %_sourcedir rpm --eval %_specdir rpm --eval %_tmppath rpm --eval %_buildroot
an. Diese Variablen lassen sich natürlich umdefinieren, was einige Paketierer machen, weil sie die Voreinstellung nicht mögen. Notfalls mußt Du diese Variablen beim Aufruf von rpmbuild umbiegen.
rpmbuild --define _sourcedir $(pwd) -ba datei.spec
Und keine Angabe von --target. Wenn Du "noarch" brauchst, gehört diese Angabe in die spec. BuildArch: noarch
Also entweder ich hab irgend was Grundsätzliches an rpmbuild noch nicht verstanden, oder das Tool ist echt für den Ar***.
Ersteres. ;)
Weitere Antworten von mir bitte nicht vor Mitte nächster Woche erwarten.
On Fri, 2 Mar 2012 18:32:29 +0100, MS (Michael) wrote:
<snip> [...] + cd /home/or/rpmbuild/BUILD
(!)
- make PREFIX=/home/or/rpmbuild/BUILDROOT/rpm-uebung-1-1.noarch pre-rpm
make[1]: Entering directory `/home/or/rpmbuild/BUILD'
(!)
make[1]: *** Keine Regel, um >>pre-rpm<< zu erstellen. Schluss. [...]
Ach, ich vergaß in der vorherigen Antwort noch diesen Hinweis: Das $RPM_BUILD_DIR ist zu Beginn von %prep ja _leer_ und wird entweder von %setup gefüllt (durch Entpacken von tarballs) oder manuelles Kopieren von %{SOURCEx} Dateien, was in Deiner spec nicht erledigt wird. Daher wird in dem Verzeichnis auch kein Makefile gefunden.
Hi!
Michael Schwendt mschwendt@gmail.com hat am 2. März 2012 um 19:02 geschrieben: [...]
Ach, ich vergaß in der vorherigen Antwort noch diesen Hinweis: Das $RPM_BUILD_DIR ist zu Beginn von %prep ja _leer_ und wird entweder von %setup gefüllt (durch Entpacken von tarballs) oder manuelles Kopieren von %{SOURCEx} Dateien, was in Deiner spec nicht erledigt wird. Daher wird in dem Verzeichnis auch kein Makefile gefunden.
Ja, also ein Henne-Ei-Problem.
Gruß
Olaf
Hallo Liste!
Danke für die Mails.
Michael Schwendt mschwendt@gmail.com hat am 2. März 2012 um 18:32 geschrieben:
On Thu, 1 Mar 2012 22:34:24 +0100 (CET), OR (Olaf) wrote:
[...]
Eigentlich ist das "pre-rpm" zu viel, denn es sollte vom Speck-File aufgerufen werden...
Sicherlich kein Tippfehler, also lassen wir es doch bei "spec", okay?
Ich habe nur zu schnell auf "Okay" geklickt, als die Rechtschreibkorrektur den Vorschlag gemacht hat (Die kennt nur "Speck" und nicht "spec").
<snip> %prep %setup -q make PREFIX=$RPM_BUILD_ROOT pre-rpm <snap>
Doch dieser Befehl wird nie ausgeführt. Ich habe nie wirklich verstanden was "%setup -q",
Im Gegensatz zu %prep ist %setup ein Kommando mit hinreichend gut dokumentierten Optionen. Laß für den Anfang -q ("quiet") weg, damit in der Ausgabe nichts unterdrückt wird. %setup ist für das Anlegen des "Build" Verzeichnisses und das Entpacken der "Source" Archive zuständig.
Also müsste zu dem Zeitpunkt, wo "%setup" abgearbeitet wird, vom Makefile die Software gebaut, als Tar-Arch verschnürt und in [wo-immer]/SOURCE/ abgeschoben worden sein.
Das gibt - theoretisch - zwei Probleme:
1.) Wenn u.a. das Verzeichnis "[wo-immer]/SOURCE/" erst von "%setup" angelegt wird, kann da noch nix drinnen sein. Auch kein Tar-Archiv. 2.) Kann Make das Tar-Archiv nicht erstellen und verschieben, wenn es nicht zuvor von rpmbuild aufgerufen wird, und gesagt bekommt, wo es das Tar-Archiv hinschieben soll.
<snip> make PREFIX=%(echo $HOME)/rpmbuild/ pre-rpm <snap>
Dieser PREFIX ist auch falsch. Ohne Kommentierung sogar unsinnig. Üblich wäre PREFIX=/usr bzw. PREFIX=%{_prefix}.
Noch mehr "schwarze Magie". Ich hab jetzt erst mal <snip> %install make PREFIX=$RPM_BUILD_ROOT install <snap> ...genommen. Auch falsch?
[...]
Und keine Angabe von --target. Wenn Du "noarch" brauchst, gehört diese Angabe in die spec. BuildArch: noarch
Ah-ja. Der Tipp ist gut.
Gruß
Olaf
On Sun, 4 Mar 2012 09:39:49 +0100 (CET), OR (Olaf) wrote:
Im Gegensatz zu %prep ist %setup ein Kommando mit hinreichend gut dokumentierten Optionen. Laß für den Anfang -q ("quiet") weg, damit in der Ausgabe nichts unterdrückt wird. %setup ist für das Anlegen des "Build" Verzeichnisses und das Entpacken der "Source" Archive zuständig.
Also müsste zu dem Zeitpunkt, wo "%setup" abgearbeitet wird, vom Makefile die Software gebaut, als Tar-Arch verschnürt und in [wo-immer]/SOURCE/ abgeschoben worden sein.
Das gibt - theoretisch - zwei Probleme:
1.) Wenn u.a. das Verzeichnis "[wo-immer]/SOURCE/" erst von "%setup" angelegt wird, kann da noch nix drinnen sein. Auch kein Tar-Archiv.
Doch. Ich erwähnte %_sourcedir bereits. Das ist der Platz für SourceX Dateien. Wenn Du %setup nicht verwendest, muß Du in %prep halt die SourceX Dateien selber in das noch leere build Verzeichnis kopieren. Das fehlte in Deiner spec Datei bislang.
Nimm zum Verständnis einfach ein geändertes Szenario an. Installation (bzw. Auspacken) eines src.rpm Paketes: rpm -ivh beispiel.src.rpm Das src.rpm ist vollständig, d.h. die enthaltenden Dateien sind danach innerhalb der spec Datei verwendbar, wurden je nach Konfiguration der rpmbuild Pfade jedoch in unterschiedliche Verzeichnisse extrahiert.
2.) Kann Make das Tar-Archiv nicht erstellen und verschieben, wenn es nicht zuvor von rpmbuild aufgerufen wird, und gesagt bekommt, wo es das Tar-Archiv hinschieben soll.
Das ergibt so keinen Sinn. Siehe oben. Ein src.rpm liefert vollständigen Inhalt. Dieser Inhalt fehlte bei Dir jedoch noch.
Du könntest durchaus Dein "make dist-tar" verwenden, um den tarball zu erzeugen, und dann mit rpmbuild weitermachen. Voraussetzung dafür ist, daß der tarball in %_sourcedir verfügbar gemacht wird. Auch für den Umweg über ein src.rpm:
dist-rpm: dist-tar [...] rpmbuild -bs beispiel.spec --define _sourcedir $(pwd) --define _srcrpmdir $(pwd) rpmbuild --rebuild beispiel.src.rpm
Das Resultat ….noarch.rpm findet sich dann natürlich nicht in $(pwd).
make PREFIX=%(echo $HOME)/rpmbuild/ pre-rpm
<snap>
Dieser PREFIX ist auch falsch. Ohne Kommentierung sogar unsinnig. Üblich wäre PREFIX=/usr bzw. PREFIX=%{_prefix}.
Noch mehr "schwarze Magie".
Warum das? Entweder Du hast im Makefile Variablen definiert, die Du im RPM Paket abändern _möchtest_ oder mußt, oder nicht. PREFIX=$prefix ist ja üblicherweise auf /usr/local eingestellt. Das könntest Du im RPM auch so lassen. Distributionen installieren jedoch nach /usr, müssen da also eine Änderung vornehmen. Besonders wichtig, wenn solche Variablenwerte von Make in das Programm (oder Skript) eingesetzt werden.
Ich hab jetzt erst mal
<snip> %install make PREFIX=$RPM_BUILD_ROOT install <snap> ...genommen. Auch falsch?
Ja. Zum einen fehlt ein Zeilenumbruch zwischen %install und make. %install ist kein Kommando. Zum anderen möchtest Du sehr wahrscheinlich $RPM_BUILD_ROOT als ein Präfix verwenden. So wie $DESTDIR in tausenden von Autoconf/Automake Projekten. Dort wird $(DESTDIR) beim Installieren von Dateien einfach vor jeden Zielpfad im Makefile gehängt. Im RPM Paket führt das zu:
make DESTDIR=$RPM_BUILD_ROOT install
Hast Du keine DESTDIR Variable, wird sowas nötig sein, damit /usr nicht fehlt:
make PREFIX=$RPM_BUILD_ROOT/usr install
Am Donnerstag, den 01.03.2012, 22:34 +0100 schrieb Olaf Radicke:
Hi!
Langsam entwickele ich einen richtigen inbrünstigen Hass auf rpm/rpmbuild.
Wenn ihr euch mal mein Beispiel anseht: https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package/de#Make...
Dann fällt euch vielleicht im Makefile diese Zeile auf...
Warum überhaupt ein Makefile? Das hat nichts mit rpmbuild zu tun und verkompliziert die Sache zusätzlich - was dem Verständnis nicht gerade dienlich ist. Im Gegenteil: Du automatisierst bestimmte Schritte (z. B. Source0 nach SOURCES kopieren), also muss man sie nicht mehr durchführen. Übung macht bekanntlich den Meister, also lass das die Leute doch selbst machen. Lass am besten das ganze Makefile weg, denn das ist echt eine ganz andere Baustelle.
Die URL suggeriert zudem, dass es eine Übersetzung des englischen Artikels ist, aber Du machst was ganz anderes. Und sollte die URL dann nicht lauten: https://fedoraproject.org/wiki/Wie_man_ein_GNU_Hello_RPM_Paket_erstellt/de oder https://fedoraproject.org/wiki/Ein_GNU_Hello_RPM_Paket_erstellen/de ?
<snip> dist-rpm: pre-rpm <snap>
Eigentlich ist das "pre-rpm" zu viel, denn es sollte vom Speck-File aufgerufen werden...
Mhh, Speck, lecker! ;)
<snip> %prep %setup -q make PREFIX=$RPM_BUILD_ROOT pre-rpm <snap>
Doch dieser Befehl wird nie ausgeführt. Ich habe nie wirklich verstanden was "%setup -q", aber offenbar führt er dazu, das "%prep" nicht ausgeführt wird.
%setup nimmt den source tarball aus SOURCES, entpackt ihn und wechselt in den neu entstandenen Ordner. Also versuchst Du, den tarball zu entpacken, bevor Du ihn mit make pre-rpm überhaupt nach SOURCES kopiert hast. Wie Du richtig sagst ein Henne-Ei-Problem.
Wenn ich "%setup -q" woanders hin verschiebe, wird "%prep" auf ein mal ausgeführt:
<snip> [...] + cd /home/or/rpmbuild/BUILD + make PREFIX=/home/or/rpmbuild/BUILDROOT/rpm-uebung-1-1.noarch pre-rpm make[1]: Entering directory `/home/or/rpmbuild/BUILD' make[1]: *** Keine Regel, um >>pre-rpm<< zu erstellen. Schluss. [...]
<snap>
Der prefix ist definitiv falsch. Also ersetze ich die Zeile durch...
<snip> make PREFIX=%(echo $HOME)/rpmbuild/ pre-rpm <snap>
Nun lautet die Fehlermeldung....
<snip> [...] Ausführung(%prep): /bin/sh -e /var/tmp/rpm-tmp.N9C8lB + umask 022 + cd /home/or/rpmbuild/BUILD + make PREFIX=/home/or/rpmbuild/ pre-rpm make[1]: Entering directory `/home/or/rpmbuild/BUILD' make[1]: *** Keine Regel, um >>pre-rpm<< zu erstellen. Schluss. [...] <snap>
...Ja? Warum sollte jetzt das Makefile auf ein mal in /home/or/rpmbuild/BUILD sein?
Weil 'cd /home/or/rpmbuild/BUILD' teil des %setup Makros ist. Details dazu unter http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-macros.html
Irgend wie scheint sich auf ein mal rpmbuild nicht mehr zuständig zu fühlen, das Tar-Archif dort hin auszupacken, wo es es gerne hin haben will...
Also wenn ich das richtig sehe, gibt es hier ein Henne-Ei-Problem (http://de.wikipedia.org/wiki/Henne-Ei-Problem):
Das Makefile brauch Informationen von rpmbuild mit es die nötigen Vorbereitungen treffen kann, mit rpmbuild funktioniert. rpmbuild braucht wiederum wiederum Informationen von Makefile.
Jetzt könnte man es sich leicht machen und ein autonomes Spec-File machen. Bei einem Projekt mit einer Bash-Datei kein Problem. Aber bei einem Großen Projekt mit hunderten Dateien wird man ja schier wahnsinnig ständig zwei Files anpassen zu müssen. Zumal 95% identisch und redundant ist.
Und zwar? Was ist hier redundant?
Das Übersetzen der Quellen und das Erstellen eines Paketes sind 2 verschiedene Vorgänge. Das eine wird mit dem Makefile gemacht und das andere mit der spec. Solange man nicht beides vermischt ist da meiner Ansicht nach gar nichts redundant.
Also entweder ich hab irgend was Grundsätzliches an rpmbuild noch nicht verstanden, oder das Tool ist echt für den Ar***.
Ich vermute ersteres.
Beste Grüße, Christoph
Hi Christoph!
Christoph Wickert christoph.wickert@googlemail.com hat am 2. März 2012 um 21:33 geschrieben:
Am Donnerstag, den 01.03.2012, 22:34 +0100 schrieb Olaf Radicke:
Hi!
Langsam entwickele ich einen richtigen inbrünstigen Hass auf rpm/rpmbuild.
Wenn ihr euch mal mein Beispiel anseht: https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package/de#Make...
Dann fällt euch vielleicht im Makefile diese Zeile auf...
Warum überhaupt ein Makefile? Das hat nichts mit rpmbuild zu tun und verkompliziert die Sache zusätzlich - was dem Verständnis nicht gerade dienlich ist. Im Gegenteil: Du automatisierst bestimmte Schritte (z. B. Source0 nach SOURCES kopieren), also muss man sie nicht mehr durchführen. Übung macht bekanntlich den Meister, also lass das die Leute doch selbst machen. Lass am besten das ganze Makefile weg, denn das ist echt eine ganz andere Baustelle.
Software fällt nicht vom Himmel. Die wird von Softwareentwicklern gemacht. Zu 99,9% wird ein Entwickler(-Team) zuerst ein Buildsstem wie make, cmake, qmake, ant oder der gleichen verwenden. rpmbuild ist das letzte Glied in dem Erstellungsprozess.
Gute Entwickler hassen es Dinge zweimal tun zu müssen. Wenn du mit rpmbuild Entwickler zwingst alle doppelt machen zu müssen, wirst du auf Granit beißen. make ist steinalt. Die Schnittstellen haben sich in den Jahren kaum geändert. In make hast du dich schnell eingearbeitet. Nach ca. 30 Min. hast du dein erste funktionierendes Makefile gebaut. Nach einer Woche bist du "make-Guru". Die Arbeitsweise von make ist Transparenz und wenig überraschend (im negativen Sinne).
Wie schaut es bei rpm aus? Nach einer halben Stunde bist du mit rpm noch nicht viel weiter als am Anfang. Nach einer Woche tut es rpmbuild irgend wie, aber nicht so wie du es willst. Das Hauptproblem ist - aus meiner Sicht - das zu viel mit "schwarzer Magie" gearbeitet wird. Es passieren zu viel Dinge im Hintergrund mit überraschendem Resultat. Das es viel Doku zu rpmbuild gibt, werde ich nicht unbedingt als Plus. Offenbar ist rpmbuild ohne umfassende Erläuterung unbedienbar.
Erschwerend kommt hinzu, das rpm es nicht geschafft hat ein selbständiges Projekt zu werden, was die Entwicklung zentral vorantreibt. Stattdessen sieht sich der Entwickler mit einen regelrechten Zoo gepachter RPM-Versionen verschiedenster Distributionen konfrontiert. Und zu allem Überfluss, hat jede Distribution noch ihre eigenen "ungeschriebenen Gesetze" also Konventionen.
Die URL suggeriert zudem, dass es eine Übersetzung des englischen Artikels ist, aber Du machst was ganz anderes. Und sollte die URL dann nicht lauten: https://fedoraproject.org/wiki/Wie_man_ein_GNU_Hello_RPM_Paket_erstellt/de oder https://fedoraproject.org/wiki/Ein_GNU_Hello_RPM_Paket_erstellen/de ?
Sollte es möglich sein, tatsächlich eine gültige Lösung zu finden, für das an sich triviale Problem, bin ich absolut dafür, sich ein zutreffenden Namen für den Artikel zu überlegen.
<snip> %prep %setup -q make PREFIX=$RPM_BUILD_ROOT pre-rpm <snap>
Doch dieser Befehl wird nie ausgeführt. Ich habe nie wirklich verstanden was "%setup -q", aber offenbar führt er dazu, das "%prep" nicht ausgeführt wird.
%setup nimmt den source tarball aus SOURCES, entpackt ihn und wechselt in den neu entstandenen Ordner. Also versuchst Du, den tarball zu entpacken, bevor Du ihn mit make pre-rpm überhaupt nach SOURCES kopiert hast. Wie Du richtig sagst ein Henne-Ei-Problem.
Egal ob ich die Zeile... make RPM_ROOT=$RPM_BUILD_ROOT set-rpm
...nach setup oder pre-rpm schiebe: es geht nicht.
Gruß
Olaf
On Sun, 4 Mar 2012 10:32:57 +0100 (CET), OR (Olaf) wrote:
Wie schaut es bei rpm aus? Nach einer halben Stunde bist du mit rpm noch nicht viel weiter als am Anfang.
Das glaubt Dir doch niemand. "Make" ist komplexer. Deine Schwierigkeiten mit rpmbuild begründen sich darin, daß Du nicht zuerst ein src.rpm für Dein Projekt baust. Das wäre eine einfache Übung. Integration von rpmbuild in ein Makefile ist etwas schwieriger. Bei RPM liefert man nämlich src.rpm Pakete aus, nicht tar Pakete.
Nach einer Woche tut es rpmbuild irgend wie, aber nicht so wie du es willst. Das Hauptproblem ist - aus meiner Sicht - das zu viel mit "schwarzer Magie" gearbeitet wird. Es passieren zu viel Dinge im Hintergrund mit überraschendem Resultat.
Was hat Dich überrascht? Daß rpmbuild einen Verzeichnisbaum voraussetzt? Andernfalls würde das Arbeiten mit vielen [src].rpm Paketen *sehr* unübersichtlich geraten. Es ist sehr hilfreich, daß rpmbuild einem hierbei Arbeit abnimmt.
Erschwerend kommt hinzu, das rpm es nicht geschafft hat ein selbständiges Projekt zu werden, was die Entwicklung zentral vorantreibt. Stattdessen sieht sich der Entwickler mit einen regelrechten Zoo gepachter RPM-Versionen verschiedenster Distributionen konfrontiert.
Ach Bitte, das gehört jetzt nicht zu diesem Thema. Die volle Geschichte ist nicht so einfach zu erzählen, wie Du es hier zusammenzufassen versuchst. rpm.org und rpm5.org sind zwei verschiedene Paar Schuhe.
Und zu allem Überfluss, hat jede Distribution noch ihre eigenen "ungeschriebenen Gesetze" also Konventionen.
Die von Fedora sind dokumentiert.
Am Sonntag, den 04.03.2012, 10:32 +0100 schrieb Olaf Radicke:
Software fällt nicht vom Himmel. Die wird von Softwareentwicklern gemacht. Zu 99,9% wird ein Entwickler(-Team) zuerst ein Buildsstem wie make, cmake, qmake, ant oder der gleichen verwenden. rpmbuild ist das letzte Glied in dem Erstellungsprozess.
Richtig, deshalb sollte man die anderen Schritte nicht in einem HowTo über *rpm* behandeln. Dann könnte man gleich noch beschreiben, wie man die Software überhaupt programmiert. Ist das in diesem Kontext wichtig oder hilfreich?
Gute Entwickler hassen es Dinge zweimal tun zu müssen. Wenn du mit rpmbuild Entwickler zwingst alle doppelt machen zu müssen, wirst du auf Granit beißen.
Was haben Entwickler überhaupt mit Paketierung zu tun? Und was müssen sie da doppelt machen?
make ist steinalt. Die Schnittstellen haben sich in den Jahren kaum geändert. In make hast du dich schnell eingearbeitet. Nach ca. 30 Min. hast du dein erste funktionierendes Makefile gebaut. Nach einer Woche bist du "make-Guru". Die Arbeitsweise von make ist Transparenz und wenig überraschend (im negativen Sinne).
Als jemand, der sich beruflich und privat auch mit dem Schreiben von Makefiles beschäftig, kann ich das nicht bestätigen.
make hat laut manpage 26 Optionen, rpmbuild nur 14.
Wie schaut es bei rpm aus? Nach einer halben Stunde bist du mit rpm noch nicht viel weiter als am Anfang. Nach einer Woche tut es rpmbuild irgend wie, aber nicht so wie du es willst. Das Hauptproblem ist - aus meiner Sicht - das zu viel mit "schwarzer Magie" gearbeitet wird. Es passieren zu viel Dinge im Hintergrund mit überraschendem Resultat.
Es passieren nur dann Dinge im Hintergrund, wenn man Makros nimmt, die extra dazu geschrieben wurden, wiederkehrende Aufgaben zu vereinfachen. Du kannst in einem spec file mit shell code arbeiten - genau wie bei make.
Das es viel Doku zu rpmbuild gibt, werde ich nicht unbedingt als Plus. Offenbar ist rpmbuild ohne umfassende Erläuterung unbedienbar.
$ man rpmbuild | wc 172 816 6897 $ man make | wc 152 1482 10358
Sieh an, für make braucht es eine umfangreichere Dokumentation. ;)
Erschwerend kommt hinzu, das rpm es nicht geschafft hat ein selbständiges Projekt zu werden, was die Entwicklung zentral vorantreibt. Stattdessen sieht sich der Entwickler mit einen regelrechten Zoo gepachter RPM-Versionen verschiedenster Distributionen konfrontiert.
Trotz Patches verhalten sich die Versionen eigentlich ziemlich gleich.
Und zu allem Überfluss, hat jede Distribution noch ihre eigenen "ungeschriebenen Gesetze" also Konventionen.
Egal ob ich die Zeile... make RPM_ROOT=$RPM_BUILD_ROOT set-rpm
...nach setup oder pre-rpm schiebe: es geht nicht.
Weil Du anscheinend immer noch %setup mit den falschen Parametern nutzt. Hast Du den Link gelesen, den ich Dir gegeben habe? Tip: versuch mal "-a"
Die richtige Herangehensweise wäre: 1. Quellen müssen ein spec file enthalten, meinetwegen auch ein *.spec.in, wenn es in der Datei noch was zu bearbeiten gibt, z. B. die Versionsnummer. 2. Mit dem Target make-dist einen fertigen Tarball erstellen. spec file muss im Wurzelverzeichnis liegen und den gleichen Namen haben wie das Archiv. 3. Dann noch ein make-rpm Target machen, das einfach rpmbuild -ta <tarball> aufruft. 4. Bei Bedarf noch ein Target, dass beides kombiniert.
Schreib also erst mal das spec, so dass es von Hand baut. Dann das Makefile darum herum bauen, sollte für Dich kein Problem sein.
Beste Grüße, Christoph
Hi Christoph!
Christoph Wickert christoph.wickert@googlemail.com hat am 4. März 2012 um 22:20 geschrieben:
Am Sonntag, den 04.03.2012, 10:32 +0100 schrieb Olaf Radicke:
[...]
Die richtige Herangehensweise wäre: 1. Quellen müssen ein spec file enthalten, meinetwegen auch ein *.spec.in, wenn es in der Datei noch was zu bearbeiten gibt, z. B. die Versionsnummer. 2. Mit dem Target make-dist einen fertigen Tarball erstellen. spec file muss im Wurzelverzeichnis liegen und den gleichen Namen haben wie das Archiv. 3. Dann noch ein make-rpm Target machen, das einfach rpmbuild -ta <tarball> aufruft. 4. Bei Bedarf noch ein Target, dass beides kombiniert.
Schreib also erst mal das spec, so dass es von Hand baut. Dann das Makefile darum herum bauen, sollte für Dich kein Problem sein.
Der Ansatz sieht vielversprechend aus. Ich werde das mal auf dem Weg versuchen umzusetzen.
Danke & Gruß
Olaf
Am Sonntag, den 04.03.2012, 22:48 +0100 schrieb Olaf Radicke:
Christoph Wickert christoph.wickert@googlemail.com hat am 4. März 2012 um 22:20 geschrieben:
Am Sonntag, den 04.03.2012, 10:32 +0100 schrieb Olaf Radicke:
[...]
Die richtige Herangehensweise wäre: 1. Quellen müssen ein spec file enthalten, meinetwegen auch ein *.spec.in, wenn es in der Datei noch was zu bearbeiten gibt, z. B. die Versionsnummer. 2. Mit dem Target make-dist einen fertigen Tarball erstellen. spec file muss im Wurzelverzeichnis liegen und den gleichen Namen haben wie das Archiv. 3. Dann noch ein make-rpm Target machen, das einfach rpmbuild -ta <tarball> aufruft. 4. Bei Bedarf noch ein Target, dass beides kombiniert.
Schreib also erst mal das spec, so dass es von Hand baut. Dann das Makefile darum herum bauen, sollte für Dich kein Problem sein.
Der Ansatz sieht vielversprechend aus. Ich werde das mal auf dem Weg versuchen umzusetzen.
Danke & Gruß
Keine Ursache, Olaf!
Hier ein Beispiel, mit dem ich gestern noch zu tun hatte, weil da ein Bug drin ist: https://github.com/geany/geany/blob/master/Makefile.am
Der Bug: Es wird mit dist-bzip2 ein tar.bz2 erstellt, aber rpm: dist sucht nach einem tar.gz. Aber Du verstehst, was ich meine.
Beste Grüße, Christoph
Hi!
Irgend was passt noch nicht...
Christoph Wickert christoph.wickert@googlemail.com hat am 4. März 2012 um 23:05 geschrieben:
Am Sonntag, den 04.03.2012, 22:48 +0100 schrieb Olaf Radicke:
Christoph Wickert christoph.wickert@googlemail.com hat am 4. März 2012 um 22:20 geschrieben:
Am Sonntag, den 04.03.2012, 10:32 +0100 schrieb Olaf Radicke:
[...]
Die richtige Herangehensweise wäre: 1. Quellen müssen ein spec file enthalten, meinetwegen auch ein *.spec.in, wenn es in der Datei noch was zu bearbeiten gibt, z. B. die Versionsnummer. 2. Mit dem Target make-dist einen fertigen Tarball erstellen. spec file muss im Wurzelverzeichnis liegen und den gleichen Namen haben wie das Archiv. 3. Dann noch ein make-rpm Target machen, das einfach rpmbuild -ta <tarball> aufruft. 4. Bei Bedarf noch ein Target, dass beides kombiniert.
Schreib also erst mal das spec, so dass es von Hand baut. Dann das Makefile darum herum bauen, sollte für Dich kein Problem sein.
Der Ansatz sieht vielversprechend aus. Ich werde das mal auf dem Weg versuchen umzusetzen.
or@hamburg:~/Desktop/rpm-uebung$ rpmbuild -ta ./rpm-uebung-1.tar.gz Ausführung(%prep): /bin/sh -e /var/tmp/rpm-tmp.9UGZg3 + umask 022 + cd /home/or/rpmbuild/BUILD + exit 0 Ausführung(%build): /bin/sh -e /var/tmp/rpm-tmp.liAs0N + umask 022 + cd /home/or/rpmbuild/BUILD + exit 0 Ausführung(%install): /bin/sh -e /var/tmp/rpm-tmp.hBoIKy + umask 022 + cd /home/or/rpmbuild/BUILD + make install make: *** Keine Regel, um >>install<< zu erstellen. Schluss. Fehler: Fehler-Status beim Beenden von /var/tmp/rpm-tmp.hBoIKy (%install)
Fehler beim Bauen des RPM: Fehler-Status beim Beenden von /var/tmp/rpm-tmp.hBoIKy (%install) or@hamburg:~/Desktop/rpm-uebung$ man tar or@hamburg:~/Desktop/rpm-uebung$ tar -tvf ./rpm-uebung-1.tar.gz drwxrwxr-x or/or 0 2012-03-05 09:36 rpm-uebung-1/ -rw-r--r-- or/or 860 2012-03-05 09:36 rpm-uebung-1/Makefile drwxrwxr-x or/or 0 2012-03-05 09:36 rpm-uebung-1/src/ -rw-r--r-- or/or 23 2012-03-05 09:36 rpm-uebung-1/src/rpm-uebung.sh -rw-r--r-- or/or 22 2012-03-05 09:36 rpm-uebung-1/src/rpm-uebung.sh~ -rw-rw-r-- or/or 351 2012-03-05 09:36 rpm-uebung-1/rpm-uebung-1.spec
Natürlich gibt es ein "install"-Befehl. Ich vermute mal, die Dateien liegen wieder nicht da, wo sie erwartet werden.
Gruß
Olaf
Am Montag, den 05.03.2012, 09:45 +0100 schrieb Olaf Radicke:
Hi!
Irgend was passt noch nicht...
[...]
Natürlich gibt es ein "install"-Befehl. Ich vermute mal, die Dateien liegen wieder nicht da, wo sie erwartet werden.
Ich vermute mal, Du verwendest immer noch %setup -q?
Beste Grüße, Christoph
Christoph Wickert christoph.wickert@googlemail.com hat am 5. März 2012 um 09:57 geschrieben:
Am Montag, den 05.03.2012, 09:45 +0100 schrieb Olaf Radicke:
Hi!
Irgend was passt noch nicht...
[...]
Natürlich gibt es ein "install"-Befehl. Ich vermute mal, die Dateien liegen wieder nicht da, wo sie erwartet werden.
Ich vermute mal, Du verwendest immer noch %setup -q?
Ne:
<snip> Summary: GNU rpm-uebung License: GPL Name: rpm-uebung Version: 1 Release: 1 Source: rpm-uebung-1.tar.gz Group: Development/Tools BuildArch: noarch BuildRoot: /var/tmp/%{name}-buildroot
%description create a Hello RPM.
%setup
%prep
%build
%install make install
%files %defattr(0755,root,root) /usr/bin/rpm-uebung.sh <snep>
Gruß
Olaf
On Mon, 5 Mar 2012 10:08:03 +0100 (CET), OR (Olaf) wrote:
Am Montag, den 05.03.2012, 09:45 +0100 schrieb Olaf Radicke:
Hi!
Irgend was passt noch nicht...
[...]
Natürlich gibt es ein "install"-Befehl. Ich vermute mal, die Dateien liegen wieder nicht da, wo sie erwartet werden.
Ich vermute mal, Du verwendest immer noch %setup -q?
Ne:
<snip> Summary: GNU rpm-uebung License: GPL Name: rpm-uebung Version: 1 Release: 1 Source: rpm-uebung-1.tar.gz Group: Development/Tools BuildArch: noarch BuildRoot: /var/tmp/%{name}-buildroot
%description create a Hello RPM.
%setup
Hier im Nirgendwo wird nichts ausgeführt. Das %setup Kommando gehört immer _in_ die %prep Sektion.
%prep
%build
%install make install
Wird so nicht funktionieren, weil Du ins $RPM_BUILD_ROOT installieren sollst/mußt, die dazu gegebenen Hinweise also nicht ignorieren solltest.
Michael Schwendt mschwendt@gmail.com hat am 5. März 2012 um 10:19 geschrieben:
On Mon, 5 Mar 2012 10:08:03 +0100 (CET), OR (Olaf) wrote:
Am Montag, den 05.03.2012, 09:45 +0100 schrieb Olaf Radicke:
Hi!
Irgend was passt noch nicht...
[...]
Natürlich gibt es ein "install"-Befehl. Ich vermute mal, die Dateien liegen wieder nicht da, wo sie erwartet werden.
Ich vermute mal, Du verwendest immer noch %setup -q?
Ne:
<snip> Summary: GNU rpm-uebung License: GPL Name: rpm-uebung Version: 1 Release: 1 Source: rpm-uebung-1.tar.gz Group: Development/Tools BuildArch: noarch BuildRoot: /var/tmp/%{name}-buildroot
%description create a Hello RPM.
%setup
Hier im Nirgendwo wird nichts ausgeführt. Das %setup Kommando gehört immer _in_ die %prep Sektion.
Von der Syntax her, ist eine Section von einem Macro/Befehl her nicht zu unterscheiden. Aber ja, das war ein Fehler und wurde von mir korrigiert.
%prep
%build
%install make install
Wird so nicht funktionieren, weil Du ins $RPM_BUILD_ROOT installieren sollst/mußt, die dazu gegebenen Hinweise also nicht ignorieren solltest.
Ja, hab ich wieder rein kopiert...
<sinp> %install make PREFIX=$RPM_BUILD_ROOT install <snap>
Sieht besser aus:
<snip>
or@hamburg:~/Desktop/rpm-uebung$ make dist-rpm rpmbuild -ta rpm-uebung-1.tar.gz Ausführung(%prep): /bin/sh -e /var/tmp/rpm-tmp.vSabji + umask 022 + cd /home/or/rpmbuild/BUILD + cd /home/or/rpmbuild/BUILD + rm -rf rpm-uebung-1 + /usr/bin/gzip -dc /home/or/Desktop/rpm-uebung/rpm-uebung-1.tar.gz + /bin/tar -xvvf - drwxrwxr-x or/or 0 2012-03-05 10:53 rpm-uebung-1/ -rw-r--r-- or/or 860 2012-03-05 10:53 rpm-uebung-1/Makefile drwxrwxr-x or/or 0 2012-03-05 10:53 rpm-uebung-1/src/ -rw-r--r-- or/or 23 2012-03-05 10:53 rpm-uebung-1/src/rpm-uebung.sh -rw-r--r-- or/or 22 2012-03-05 10:53 rpm-uebung-1/src/rpm-uebung.sh~ -rw-rw-r-- or/or 352 2012-03-05 10:53 rpm-uebung-1/rpm-uebung-1.spec + STATUS=0 + '[' 0 -ne 0 ']' + cd rpm-uebung-1 + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + exit 0 Ausführung(%build): /bin/sh -e /var/tmp/rpm-tmp.IAqIwB + umask 022 + cd /home/or/rpmbuild/BUILD + cd rpm-uebung-1 + exit 0 Ausführung(%install): /bin/sh -e /var/tmp/rpm-tmp.TTDeLU + umask 022 + cd /home/or/rpmbuild/BUILD + cd rpm-uebung-1 + make PREFIX=/home/or/rpmbuild/BUILDROOT/rpm-uebung-1-1.i386 install make[1]: Entering directory `/home/or/rpmbuild/BUILD/rpm-uebung-1' [ -d /home/or/rpmbuild/BUILDROOT/rpm-uebung-1-1.i386/usr/bin/ ] || mkdir -p /home/or/rpmbuild/BUILDROOT/rpm-uebung-1-1.i386/usr/bin/ ./src/rpm-uebung.sh /home/or/rpmbuild/BUILDROOT/rpm-uebung-1-1.i386/usr/bin/ make[1]: execvp: ./src/rpm-uebung.sh: Keine Berechtigung make[1]: *** [install] Fehler 127 make[1]: Leaving directory `/home/or/rpmbuild/BUILD/rpm-uebung-1' Fehler: Fehler-Status beim Beenden von /var/tmp/rpm-tmp.TTDeLU (%install)
Fehler beim Bauen des RPM: Fehler-Status beim Beenden von /var/tmp/rpm-tmp.TTDeLU (%install) make: *** [dist-rpm] Fehler 1 <snap>
Das Problem mit den Berechtigungen ist mir aber nicht klar:
<snip> or@hamburg:~/Desktop/rpm-uebung$ ls -lah /home/or/rpmbuild/BUILDROOT/rpm-uebung-1-1.i386/usr/bin/ insgesamt 8,0K drwxr-xr-x 2 or or 4,0K 5. Mär 10:53 . drwxr-xr-x 3 or or 4,0K 5. Mär 10:53 .. <snap>
Gruß
Olaf
On Mon, 5 Mar 2012 11:18:22 +0100 (CET), OR (Olaf) wrote:
./src/rpm-uebung.sh /home/or/rpmbuild/BUILDROOT/rpm-uebung-1-1.i386/usr/bin/ make[1]: execvp: ./src/rpm-uebung.sh: Keine Berechtigung
Das ist so sicherlich nicht gedacht. Du willst die Datei doch kopieren:
cp -p src/rpm-uebung.sh ${RPM_BUILD_ROOT}/usr/bin
Das Problem mit den Berechtigungen ist mir aber nicht klar:
<snip> or@hamburg:~/Desktop/rpm-uebung$ ls -lah /home/or/rpmbuild/BUILDROOT/rpm-uebung-1-1.i386/usr/bin/ insgesamt 8,0K drwxr-xr-x 2 or or 4,0K 5. Mär 10:53 . drwxr-xr-x 3 or or 4,0K 5. Mär 10:53 .. <snap>
Du versuchst rpm-uebung.sh auszuführen, was wegen Mode 0644 nicht funktioniert.
Michael Schwendt mschwendt@gmail.com hat am 5. März 2012 um 11:41 geschrieben:
On Mon, 5 Mar 2012 11:18:22 +0100 (CET), OR (Olaf) wrote:
./src/rpm-uebung.sh /home/or/rpmbuild/BUILDROOT/rpm-uebung-1-1.i386/usr/bin/ make[1]: execvp: ./src/rpm-uebung.sh: Keine Berechtigung
Das ist so sicherlich nicht gedacht. Du willst die Datei doch kopieren:
cp -p src/rpm-uebung.sh ${RPM_BUILD_ROOT}/usr/bin
Das Problem war eine Undefinierte Variable im Makefile. Jetzt funktioniert es aber. Der weg ist definitiv schmerzfreier als mein erster Ansatz. Ich hatte noch nach einen "-o" Flag gesucht, um bestimmen zu können, wo das rpm abgelegt wird. Oder auch überhaupt eine Doku zu den "-tX"-Flags.
Ich werde den Artikel jetzt noch mal umbauen und meine neuen Erkenntnisse einflissen lassen. Wir könnten hier derweil diskutieren, wie der Artikel heißen soll und wo er hin passt.
Gruß
Olaf
Guten Morgen Leute!
Ich hab jetzt - wie angekündigt - den Artikel komplett überarbeitet. Der Link noch mal:
https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package/de
Es gibt bestimmt noch Dinge die man noch besser machen kann. Vor allem ist zu überlegen welcher der beste Titel ist, wo der Artikel hin verschoben werden sollte und ober er überhaupt im Fedora-Projekt verbleiben soll. Es gibt ja noch weitere Wikis mit Linux-Thematik.
Gruß
Olaf
On Tue, 6 Mar 2012 10:39:31 +0100 (CET), OR (Olaf) wrote:
Guten Morgen Leute!
Ich hab jetzt - wie angekündigt - den Artikel komplett überarbeitet. Der Link noch mal:
https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package/de
Es gibt bestimmt noch Dinge die man noch besser machen kann. Vor allem ist zu überlegen welcher der beste Titel ist, wo der Artikel hin verschoben werden sollte und ober er überhaupt im Fedora-Projekt verbleiben soll. Es gibt ja noch weitere Wikis mit Linux-Thematik.
Da hast Du recht. Der Titel des Artikels ist unglücklich gewählt, da es ja nicht die Übersetzung des englischsprachigen Artikels ist. Eher zutreffend:
"Wie man RPM Paketerzeugung in ein GNU Makefile integriert"
Wenn Du ein deutschsprachiges Wiki kennst, in dem solche Artikel nicht nur besser aufgehoben sind, sondern auch aktiv gepflegt werden, wäre das natürlich geeigneter. Im Fedora Project Wiki scheint nur die Einstiegsseite übersetzt zu sein: http://fedoraproject.org/wiki/Fedora_Project_Wiki/de
%install make PREFIX=$RPM_BUILD_ROOT install
Auch das bleibt weiterhin unglücklich, da Du $PREFIX mißbrauchst, anstatt $DESTDIR für diesen Zweck zu nehmen:
http://www.gnu.org/software/make/manual/html_node/Directory-Variables.html http://www.gnu.org/software/make/manual/html_node/DESTDIR.html#DESTDIR
Hi!
Michael Schwendt mschwendt@gmail.com hat am 6. März 2012 um 12:07 geschrieben:
On Tue, 6 Mar 2012 10:39:31 +0100 (CET), OR (Olaf) wrote:
[...]
%install make PREFIX=$RPM_BUILD_ROOT install
Auch das bleibt weiterhin unglücklich, da Du $PREFIX mißbrauchst, anstatt $DESTDIR für diesen Zweck zu nehmen:
Ich hab noch mal in mein schlaues Buche geschaut (ISBN:3826614429) das nicht nur GNU make behandelt. So wie ich es verstehe ist "$DESTDIR" nur eine Konvention. Es ist keine Standard-Variable die ein Vordefinierten Wehrt hat.
Ein kurzer Test belegt das...
test: echo $(PREFIX) $(DESTDIR)
In der qmake Variante ist "$(.PREFIX)", mit führendem Punkt definiert. Aber diese Variable hat eine völlig andere Funktion.
Gruß
Olaf
On Tue, 6 Mar 2012 23:50:26 +0100 (CET), OR (Olaf) wrote:
%install make PREFIX=$RPM_BUILD_ROOT install
Auch das bleibt weiterhin unglücklich, da Du $PREFIX mißbrauchst, anstatt $DESTDIR für diesen Zweck zu nehmen:
Ich hab noch mal in mein schlaues Buche geschaut (ISBN:3826614429) das nicht nur GNU make behandelt. So wie ich es verstehe ist "$DESTDIR" nur eine Konvention. Es ist keine Standard-Variable die ein Vordefinierten Wehrt hat.
Natürlich nicht. Falls vordefiniert, allenfalls als DESTDIR= oder DESTDIR=/ , denn sonst würden solche Makefiles ja nicht unterhalb des Root-Verzeichnisses eines Systems Dateien installieren.
Welchen vordefinierten Wert hattest Du denn im Sinn?
Ein kurzer Test belegt das...
test: echo $(PREFIX) $(DESTDIR)
echo $PREFIX $DESTDIR auf der Kommandozeile hätte es auch getan.
In der qmake Variante ist "$(.PREFIX)", mit führendem Punkt definiert. Aber diese Variable hat eine völlig andere Funktion.
$(PREFIX) anders zu verwenden als $(prefix) wäre eigensinnig und würde zu Irritationen führen. Möchtest Du das denn?
Michael Schwendt mschwendt@gmail.com hat am 7. März 2012 um 01:38 geschrieben:
On Tue, 6 Mar 2012 23:50:26 +0100 (CET), OR (Olaf) wrote:
%install make PREFIX=$RPM_BUILD_ROOT install
Auch das bleibt weiterhin unglücklich, da Du $PREFIX mißbrauchst, anstatt $DESTDIR für diesen Zweck zu nehmen:
Ich hab noch mal in mein schlaues Buche geschaut (ISBN:3826614429) das nicht nur GNU make behandelt. So wie ich es verstehe ist "$DESTDIR" nur eine Konvention. Es ist keine Standard-Variable die ein Vordefinierten Wehrt hat.
Natürlich nicht. Falls vordefiniert, allenfalls als DESTDIR= oder DESTDIR=/ , denn sonst würden solche Makefiles ja nicht unterhalb des Root-Verzeichnisses eines Systems Dateien installieren.
Welchen vordefinierten Wert hattest Du denn im Sinn?
Ein kurzer Test belegt das...
test: echo $(PREFIX) $(DESTDIR)
echo $PREFIX $DESTDIR auf der Kommandozeile hätte es auch getan.
Schreib mal...
test: echo $(RM)
...in dein (GNU) Makefile und vergleiche de Ausgabe mit der in der Bash. Dann bemerkst du dein Irrtum.
In der qmake Variante ist "$(.PREFIX)", mit führendem Punkt definiert. Aber diese Variable hat eine völlig andere Funktion.
$(PREFIX) anders zu verwenden als $(prefix) wäre eigensinnig und würde zu Irritationen führen. Möchtest Du das denn?
Weder die Eine, noch die Andere ist eine vordefinierte Variable. Es handelt sich also lediglich um eine Konvention.
Aber gut, da es eine mustergültige Lösung werden soll habe ich es geändert.
Gruß
Olaf
On Wed, 7 Mar 2012 08:12:28 +0100 (CET), OR (Olaf) wrote:
Schreib mal...
test: echo $(RM)
...in dein (GNU) Makefile und vergleiche de Ausgabe mit der in der Bash. Dann bemerkst du dein Irrtum.
Ich habe Dich nicht gebeten, nach Variablen a la AR, CC, LD, CXX, F77 in der Shell zu suchen. Natürlich sind nicht alle nur aufgrund ihrer Großschreibung Umgebungsvariablen (wie HOME, LANG, PATH, PWD und weitere). Die Kenntnis habe ich vorausgesetzt, ohne in den Untiefen von $(.VARIABLES) zu stöbern -- oder nachzuforschen, ob und wo qmake ein .PREFIX dokumentiert. In der Variablenübersicht von qmake ist das nicht aufgeführt. PREFIX bei Qt Projekten ist allerdings auch schon vorgekommen, obwohl die Installation bei qmake m.E. von Grund auf anders erfolgt. Du beziehst Dich mehrmals auf Konventionen, zeigst Dich aber -- ja, wie bezeichnet man das passend -- in der Hinsicht renitent, anstatt solche Gepflogenheiten einfach anzunehmen. Dem prefix=/usr/local (auch mit Großschreibung) und dem DESTDIR Präfix begegnet man einfach zu früh und zu häufig, um PREFIX anders zu verwenden. Analog zum "in einer Woche ist man Make-Guru". Da wäre es dann wohl besser, alle eigenen Variablen gleich in einen eigenen Namensraum zu verfrachten.
On Wed, 7 Mar 2012 11:04:28 +0100, MS (Michael) wrote:
$(.VARIABLES)
Möchte hiermit einen Tipp von einem ,,Experten'' (Zitat: "Nö, kein make Guru") weiterreichen: make -p|grep ^PREFIX
Das ist aus der "Make Database", die ist sogar kommentiert:
$ make -p|grep -A1 env|tail make: *** No targets specified and no makefile found. Stop. -- # environment QTINC = /usr/lib64/qt-3.3/include # environment QTDIR = /usr/lib64/qt-3.3 -- # environment LANG = en_US.UTF-8 # environment TERM = xterm
Hi!
Ich habe den Artikel jetzt auf Wikibooks umgezogen: http://de.wikibooks.org/wiki/Linux-Kompendium:_RPM-Pakete_mit_GNU_Make
In der Zwischenzeit habe ich das Szenario mit dem deb-Paketsystem noch mal durchexerziert. Das Ergebnis war ernüchternd: Nach einer Stunde hatte ich ein funktionierendes deb-Paket und nach drei Stunden, eine funktionierendes deb-Repos.
Was ist eigentlich das "killer feature" von rpm, das Red Hat/Fedora daran festhält?
Gruß
Olaf
Am Mittwoch, den 14.03.2012, 08:14 +0100 schrieb Olaf Radicke:
Hi!
Ich habe den Artikel jetzt auf Wikibooks umgezogen: http://de.wikibooks.org/wiki/Linux-Kompendium:_RPM-Pakete_mit_GNU_Make
In der Zwischenzeit habe ich das Szenario mit dem deb-Paketsystem noch mal durchexerziert. Das Ergebnis war ernüchternd: Nach einer Stunde hatte ich ein funktionierendes deb-Paket
Das ist wohl kaum ein fairer Vergleich. Du selbst hast gesagt, dass jemand nach einem Tag Einarbeitung ein make-guru ist. Du musst nach dieser Definition ein Oberguru sein und Debian benutzt ebenfalls make für seine rules. Du hast also Kenntnisse genutzt, die Du schon hattest, nicht aber innerhalb einer Stunde make *und* Debian-Paketierung gelernt.
Und hast du wirklich alle Dateien from scratch geschrieben oder hast Du dh-make verwendet?
und nach drei Stunden, eine funktionierendes deb-Repos.
Also hast Du 2 Stunden gebraucht, um ein Debian-Repo zu erstellen?
Was ist eigentlich das "killer feature" von rpm, das Red Hat/Fedora daran festhält?
Echtes Multi-arch, xz-Kompression, delta-rpms, dateibasierte Abhängigkeiten, Identische Dateien können in mehreren Paketen sein, die --verify Option, %ghost, u.v.a.m.
Nachteile, die ich bei deb sehe: 1. Installiert beim Bauen in den debian Ordner. Versuch den mal nach einen Build manuell wieder sauber zu kriegen. Man muss schauen, was 'make clean'. rpmbuild nutzt ein eigenes BUILDDIR. 2. Wenn man den Bau an einer bestimmten Stelle abbricht, beispielsweise beim Anwenden der Patches, ist das Paket in einem inkonsistenten Zustand, dann kann man weder bauen noch 'make clean' ausführen. 3. Was wenn eine Software keine autotools nutzt und kein clean Target hat? 4. Es gibt keine Standards, sondern immer 3 verschiedene Wege, etwas zu machen. Zudem 3 verschiedene Quellformate. Neue Pakete sind nicht abwärtskompatibel. 5. Der Bau hängt von der Version der verwendeten Tools ab. 6. Die Vielzahl von Dateien. Ich pflege ein Debian php5 Paket und habe in den debian Ordner ungefähr 80 Dateien (plus knapp 70 Patches) 7. dkpg hat keine Abhängigkeiten für %post, %postun, %pre oder % preun. Also kann es vorkommen, dass ein Skript hängen bleibt, weil es ein tools auführen will, das schon nicht mehr installiert ist. 'apt-get -f install' hilft dann auch nicht mehr. 8. deb hat erst seit kurzer Zeit Signaturen 9. Bei deb gibt es keinen einfachen Weg, die Integrität des orig.tar.gz zu übrprüfen.
Mir fallen bestimmt noch mehr Gründe ein, aber ich belasse es mal dabei und wende mich wieder meiner Arbeit zu - dem Bau von Debian-Paketen. :(
Beste Grüße, Christoph
Christoph Wickert christoph.wickert@googlemail.com hat am 4. März 2012 um 22:20 geschrieben:
Am Sonntag, den 04.03.2012, 10:32 +0100 schrieb Olaf Radicke:
[...]
Gute Entwickler hassen es Dinge zweimal tun zu müssen. Wenn du mit rpmbuild Entwickler zwingst alle doppelt machen zu müssen, wirst du auf Granit beißen.
Was haben Entwickler überhaupt mit Paketierung zu tun? Und was müssen sie da doppelt machen?
Wenn du in einer Firma entwickelst und du deine Software z.B. über Spacewalk verteilen willst, mit du nicht den Überblick verlierst, wo welche Versionen laufen, welche alternative zu RPM gibt es? Und wer soll die Pakete bauen, wenn nicht die Entwickler?
Wenn man das komplexe Zusammenspiel zwischen make und rpmbuild vermeiden will, und ein autonomes spec-File erstellt, hat man alles doppelt.
make ist steinalt. Die Schnittstellen haben sich in den Jahren kaum geändert.
In make hast du dich schnell eingearbeitet. Nach ca. 30 Min. hast du dein erste funktionierendes Makefile gebaut. Nach einer Woche bist du "make-Guru". Die Arbeitsweise von make ist Transparenz und wenig überraschend (im negativen Sinne).
Als jemand, der sich beruflich und privat auch mit dem Schreiben von Makefiles beschäftig, kann ich das nicht bestätigen.
make hat laut manpage 26 Optionen, rpmbuild nur 14.
Man brauch aber nur ein Bruchteil davon um loslegen zu können.
Gruß
Olaf
de-users@lists.fedoraproject.org
-
Christoph Wickert -
Fabian Affolter -
Michael Schwendt -
Olaf Radicke