Guten Abend!
Michael Schwendt mschwendt@gmail.com hat am 4. März 2012 um 11:39 geschrieben:
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.
Erst mal nicht. Als User brauchst du maximal drei Befehle: "make" & "make install". Manchmal noch eine "configure".
Als rpmbuild-User musst du wissen: 1.) Das du ein Tar-Archiv des Codes brauchst. 2.) Das er an einer ganz bestimmten stelle abgelegt werden muss (die auf unterschiedlichen Distributionen unterschiedlich sein kann). 3.) Das das Verzeichnis im Tar-Archiv den gleichen Namen haben muss (einschlislich Versionsnummer) wie das Ziel (das rpm), was nicht selbstverständlich ist. 4.) Das rpmbuild noch Parameter erwartet. Mindestens den Namen des Spec-File. Meist noch weitere, die man durch das lesen des Spec-Files oft nicht ableiten kann (im Gegensatz zu make). 5.) Das dass fertige rpm nicht dort gespeichert wird, wo man das Spec-File aufgerufen wird. 6.) Das unter bestimmten Umständen die rpmbuild-Umgebung nicht automatisch erstellt wird. 7.) Das die rpmbuild-Umgebung von mehr als einem Paket verwendet wird.
Der Aufbau von einem Makefile ist in einem Satz erklärt:
Ziel: Quelle Befehl
Zweizeiliges Beispiel:
<snip> kochrezept.pdf: kochrezept.tex pdflatex kochrezept.tex <snap>
Befehl für den User: "make" - das war es. Er User/Entwickler hat eine valides Makefile.
Das man mit make einige abgefahrenen Sachen machen kann ist ungenommen. Doch wird sich die Schnittstelle für den User dadurch nicht ändern.
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.
Entschuldigung. Ich war es von Make gewöhnt, ohne Umwege an das Ziel zu kommen.
Integration von rpmbuild in ein Makefile ist etwas schwieriger. Bei RPM liefert man nämlich src.rpm Pakete aus, nicht tar Pakete.
Gut, dann lass uns den Weg gehen, wie du meinst, das es sein muss...
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.
rpmbuild ist eindeutig für Maintainer und Distributoren gemacht. Nur sind wir Heute in der glücklichen Lage, das mehr Software für Linux hergestellt wird, als die Maintainer der Distributionen jemals verwalten können. Nicht ohne Grund gibt es so was wie EPEL.
Make ist - aus meiner Sicht - ein guter Kompromiss zwischen den Interessen
der Entwickler und der Anwender.
Bei rpmbuild müsste es eigentlich zwei Regeldateien geben. Eine, in der der Entwickler festhält was sein Programm braucht um zu arbeiten. Und eine zweite Steuerungsdatei, in der der Maintainer beschreibt wie er Software organisieren will. Im Idealfall, müssen beide nicht wissen, wie der andere arbeitet. Und
wie rpm den Bau und die Verwaltung organisiert, muss auch keinen interessieren.
Kann aber optional durch eine dritte Steuerungdatei auch noch beeinflusst werden.
Für den Fall, das es sich um einen Buildserver mit besonderen Anvorderungen
handelt.
Und zu allem Überfluss, hat jede Distribution noch ihre eigenen "ungeschriebenen Gesetze" also Konventionen.
Die von Fedora sind dokumentiert.
Sicher sind sie das! Genauso wie für Red Hat, Red Falg Linux, CentOS, SuSE Linux, Oracle Linux, Conectiva, Berry Linux, Yellow Dog Linux, Scientific Linux, Mandriva Linux http://distrowatch.com/mandriva , Mageia, uvam...
Und du erwartest tatsächlich, das Entwickler sich damit beschäftigen wollen?
Gruß
Olaf
On Sun, 4 Mar 2012 20:25:11 +0100 (CET), OR (Olaf) wrote:
Als User brauchst du maximal drei Befehle: "make" & "make install". Manchmal noch eine "configure".
Äh? "configure" hat mit "Make" erstmal überhaupt nichts zu tun. Wenn Du die Autotools in die Sache hineinziehst, geht der Spaß richtig los. Dann ist weit mehr Lesen von Dokumentation notwendig, um allein die speziellen Namensgebungsschemata für Variablen zu lernen. Es finden sich immer wieder Entwickler, die daran scheitern oder deshalb auf die Autotools verzichten und komplexe Makefiles allein schreiben wollen. Für ein einfaches Makefile für ein "Hello, world!" Programm reicht Lesen von "man make" auch nicht. Im info basierten Make Manual gibt es schon reichlich zu lesen.
Als rpmbuild-User musst du wissen: 1.) Das du ein Tar-Archiv des Codes brauchst.
Nicht zwingend.
2.) Das er an einer ganz bestimmten stelle abgelegt werden muss (die auf unterschiedlichen Distributionen unterschiedlich sein kann).
Ergibt sich [notfalls] auch aus den Fehlermeldungen.
3.) Das das Verzeichnis im Tar-Archiv den gleichen Namen haben muss (einschlislich Versionsnummer) wie das Ziel (das rpm), was nicht selbstverständlich ist.
Nicht zwingend. Das %setup Makro versteht diverse Optionen, mit denen Du auch andere "topdir" Verzeichnisnamen im tarball nutzen kannst. Hunderte, ach, Tausende source tarballs haben ein topdir $(PACKAGE_NAME)-$(PACKAGE_VERSION), nicht nur GNU Projekte.
4.) Das rpmbuild noch Parameter erwartet. Mindestens den Namen des Spec-File. Meist noch weitere, die man durch das lesen des Spec-Files oft nicht ableiten kann (im Gegensatz zu make).
Der Anfang von "man rpmbuild":
SYNOPSIS BUILDING PACKAGES: rpmbuild {-ba|-bb|-bp|-bc|-bi|-bl|-bs} [rpmbuild-options] SPECFILE ...
rpmbuild {-ta|-tb|-tp|-tc|-ti|-tl|-ts} [rpmbuild-options] TARBALL ...
rpmbuild {--rebuild|--recompile} SOURCEPKG ...
Das sind im Vergleich nun wahrlich nicht soviele Befehle, als daß sie einen erschlagen würden.
5.) Das dass fertige rpm nicht dort gespeichert wird, wo man das Spec-File aufgerufen wird.
Ist das so schlimm? rpmbuild gibt doch die Pfade am Ende deutlich zu erkennen aus.
6.) Das unter bestimmten Umständen die rpmbuild-Umgebung nicht automatisch erstellt wird.
Vage. Aber auch nicht das unüberwindliche Hindernis.
7.) Das die rpmbuild-Umgebung von mehr als einem Paket verwendet wird.
Ja nun, bist Du auf dieser Mailing-Liste, um etwas zu RPM und rpmbuild lernen zu wollen? Oder liegt Dir mehr am Herumstänkern?
rpmbuild ist eindeutig für Maintainer und Distributoren gemacht.
Allgemein: für RPM Paketierer. Und für einfache Pakete ist eine spec Datei nur eine Mischung aus Shell Skript und Config Datei. Dazu gibt es Beispiele zu Hauf.
Nur sind wir Heute in der glücklichen Lage, das mehr Software für Linux hergestellt wird, als die Maintainer der Distributionen jemals verwalten können. Nicht ohne Grund gibt es so was wie EPEL.
EPEL gibt es nur, weil es sich nicht mit dem Produkt RHEL zusammenlegen läßt wie es bei Fedora Core und Fedora Extras geschehen war. Gleiches gilt für jedes 3rd party repository. Übrigens, EPEL ist nicht unumstritten.
jede Distribution noch ihre eigenen "ungeschriebenen Gesetze" also Konventionen.
Die von Fedora sind dokumentiert.
Sicher sind sie das! Genauso wie für Red Hat, Red Falg Linux, CentOS, SuSE Linux, Oracle Linux, Conectiva, Berry Linux, Yellow Dog Linux, Scientific Linux, Mandriva Linux http://distrowatch.com/mandriva , Mageia, uvam...
Was soll Deine Aussage sein? Makefiles gleichen sich auch nicht alle. Weder reines Make/GNU Make, noch Autoconf/Automake/Libtool basierende. Du nennst Dich selbst "Make Guru". Spätestens echte Gurus leben sich manchmal in ihren Makefiles aus und verzichten z.B. auf viele implizite Regeln.
Und du erwartest tatsächlich, das Entwickler sich damit beschäftigen wollen?
Wurdest Du gezwungen, einen Wiki Artikel zum Thema "rpmbuild und Makefile Integration" zu schreiben? Wurdest Du gezwungen, zu einem Projekt nicht nur eine einfache spec Datei zu erstellen, sondern die ins Makefile zu integrieren?
Also bitte! Ganz zu Anfang erwähntest Du schon "inbrünstigen Hass auf rpm/rpmbuild". Ahnst Du, wieviele Leser da abgetörnt wegclicken und überhaupt nicht mehr daran denken, Dir eventuell zu helfen? Und auf Christophs Antwort folgt nur noch Jammerei. Wohin soll das denn führen?
Hi!
Michael Schwendt mschwendt@gmail.com hat am 4. März 2012 um 21:47 geschrieben:
On Sun, 4 Mar 2012 20:25:11 +0100 (CET), OR (Olaf) wrote:
Als User brauchst du maximal drei Befehle: "make" & "make install". Manchmal noch eine "configure".
Äh? "configure" hat mit "Make" erstmal überhaupt nichts zu tun.
Es ging um die Sicht der User auf make. Und selbst durch Autotools ändert sich nichts für die Benutzung. Die Schnittstelle/Interface bleibt gleich. Das sollte die Kernaussage sein.
Ja nun, bist Du auf dieser Mailing-Liste, um etwas zu RPM und rpmbuild lernen zu wollen? Oder liegt Dir mehr am Herumstänkern?
Wenn man was lernen will, darf man sich nicht über Ungereimtheiten wundern?
rpmbuild ist eindeutig für Maintainer und Distributoren gemacht.
Allgemein: für RPM Paketierer. Und für einfache Pakete ist eine spec Datei nur eine Mischung aus Shell Skript und Config Datei.
...Und Konventionen, hast du vergessen.
Sicher sind sie das! Genauso wie für Red Hat, Red Falg Linux, CentOS, SuSE Linux, Oracle Linux, Conectiva, Berry Linux, Yellow Dog Linux, Scientific Linux, Mandriva Linux http://distrowatch.com/mandriva , Mageia, uvam...
<Nebenbemerkung>Das Quoting meines Webmailers (OpenXchange) ist wirklich gruselig. Und dann immer diese kaputten Tags dazwischen... Peinlich.</Nebenbemerkung>
Was soll Deine Aussage sein? Makefiles gleichen sich auch nicht alle. Weder reines Make/GNU Make, noch Autoconf/Automake/Libtool basierende.
Das Interface/Bedienung für den User ist die selbe: make && make install
Du nennst Dich selbst "Make Guru".
Zitiere wörtlich! Was hatte ich geschrieben?
Spätestens echte Gurus leben sich> manchmal in ihren Makefiles aus und verzichten z.B. auf viele implizite Regeln.
Ja, und? Macht das dem User Probleme? Nö, er tipp immer noch nur: make && make install. Was der Entwickler treibt interessiert ihn nicht.
Und du erwartest tatsächlich, das Entwickler sich damit beschäftigen wollen?
Wurdest Du gezwungen, einen Wiki Artikel zum Thema "rpmbuild und Makefile Integration" zu schreiben? Wurdest Du gezwungen, zu einem Projekt nicht nur eine einfache spec Datei zu erstellen, sondern die ins Makefile zu integrieren?
Bisher dachte ich, ich gehe es nur falsch an. Aber offenbar ist es wirklich sehr verkorkst portable rpmbuild Regeln zu schreiben, die User nicht überfordern und mit einem Befehlen auskommen: make dist-rpm.
Einen guten Wochenstart!
Olaf
On Sun, 4 Mar 2012 22:33:30 +0100 (CET), OR (Olaf) wrote:
Als User brauchst du maximal drei Befehle: "make" & "make install". Manchmal noch eine "configure".
Äh? "configure" hat mit "Make" erstmal überhaupt nichts zu tun.
Es ging um die Sicht der User auf make. Und selbst durch Autotools ändert sich nichts für die Benutzung. Die Schnittstelle/Interface bleibt gleich. Das sollte die Kernaussage sein.
rpmbuild kennt nur _drei_ Aufrufarten: Angabe einer .spec Datei, Angabe eines Archives und Angabe eines src.rpm Paketes.
Du kritisiertest bisher die "Programmierung von spec Dateien", nicht die Verwendung von rpmbuild.
Mal tatsächlich angenommen, ein Nutzer möchte ein RPM Paket erstellen lassen, anstatt fertige Pakete nur zu installieren, so ist der Aufruf sehr simpel a la "rpmbuild --rebuild beispiel.src.rpm". Bietest Du kein src.rpm an, sondern ein Tar o.ä. Archiv, ist der Aufruf nur leicht anders gemäß "man rpmbuild".
Übrigens, Make beschränkt sich auch nicht "make all" und "make install". Woher weiß der Nutzer von "make install-plugins", "make clean", "make dist", "make release", "make check", "make test" und weiteren targets, die definiert sein können? Bei "configure" verhält es sich ebenso. Die angebotenen Optionen (--with-foo/--without-foo, --enable-foo/--disable-foo) variieren. Eine spec Datei läßt sich ebenfalls durch --with/--without Optionen erweitern. Ich sehe da bei der Verwendung nicht den eklatanten Unterschied, den Du auszumachen meinst.
Ja nun, bist Du auf dieser Mailing-Liste, um etwas zu RPM und rpmbuild lernen zu wollen? Oder liegt Dir mehr am Herumstänkern?
Wenn man was lernen will, darf man sich nicht über Ungereimtheiten wundern?
Doch, doch. Das "Dürfen" ist hier nicht die Frage. Nur ist das Ziel fraglich. Und die Schwerpunktsetzung auch. Eine von vornherein zu negative Sichtweise
Du nennst Dich selbst "Make Guru".
Zitiere wörtlich! Was hatte ich geschrieben?
Gerngeschehen:
| Nach ca. 30 Min. hast du dein erste funktionierendes Makefile gebaut. | Nach einer Woche bist du "make-Guru".
Sowie:
| 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.
Du willst jetzt doch nicht im Nachhinein die Meßlatte für den Make Guru-Status höherlegen, weil Du Dich etwa noch nicht eine Woche mit Make befasst hast, oder? ;-)
Bisher dachte ich, ich gehe es nur falsch an. Aber offenbar ist es wirklich sehr verkorkst portable rpmbuild Regeln zu schreiben, die User nicht überfordern und mit einem Befehlen auskommen: make dist-rpm.
Was hat denn nun Portabilität mit der Sache zu tun? Der Aufruf von rpmbuild ist doch überall gleich. Wo siehst Du denn da Probleme? Und Du willst doch sogar den User von rpmbuild abschotten und ihn stattdessen Make verwenden lassen. Die Lösung für Dein Makefile wurde mehrfach erwähnt. Und Christophs Vorschlag,
rpmbuild -ta blubb.tgz
bietet sich geradezu an, wenn Du ohnehin einen tarball erzeugst. Alternativ (und für beliebige SourceX Dateien):
rpmbuild -ba blubb.spec --define "_sourcedir $(pwd)"
Michael Schwendt mschwendt@gmail.com hat am 4. März 2012 um 23:07 geschrieben:
On Sun, 4 Mar 2012 22:33:30 +0100 (CET), OR (Olaf) wrote:
[...]
Du nennst Dich selbst "Make Guru".
Zitiere wörtlich! Was hatte ich geschrieben?
Gerngeschehen:
| Nach ca. 30 Min. hast du dein erste funktionierendes Makefile gebaut. | Nach einer Woche bist du "make-Guru".
Danke. Nun sieht man deutlich, das du meine Aussage verfälscht wiedergegeben hast.
Gruß
Olaf
Am Sonntag, den 04.03.2012, 20:25 +0100 schrieb Olaf Radicke:
Guten Abend!
Michael Schwendt mschwendt@gmail.com hat am 4. März 2012 um 11:39 geschrieben:
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.
Erst mal nicht. Als User brauchst du maximal drei Befehle: "make" & "make install". Manchmal noch eine "configure".
Als rpmbuild-User musst du wissen:
rpmbuild ist auch kein Tool für Nutzer, sondern für Entwickler und Paket-Maintainer. Ein Nutzer braucht nur rpm zu kennen.
1.) Das du ein Tar-Archiv des Codes brauchst.
Nein, es gehen auch andere Archive oder einzelne Dateien.
2.) Das er an einer ganz bestimmten stelle abgelegt werden muss (die auf unterschiedlichen Distributionen unterschiedlich sein kann).
Zeig mir eine Distribution, auf der es nicht rpmbuild/SOURCES bzw. % _topdir/SOURCES ist.
3.) Das das Verzeichnis im Tar-Archiv den gleichen Namen haben muss (einschlislich Versionsnummer) wie das Ziel (das rpm), was nicht selbstverständlich ist.
Muss es nicht, dass ist davon abhängig, was als SourceX definiert ist.
Abgesehen davon: All das braucht den Nutzer ja nicht zu interessieren, denn er bekommt ja ein fertiges Spec file, genauso wie er ein fertiges Makefile bekommt. Sonst vergleichst Du Äpfel mit Birnen.
4.) Das rpmbuild noch Parameter erwartet. Mindestens den Namen des Spec-File. Meist noch weitere, die man durch das lesen des Spec-Files oft nicht ableiten kann (im Gegensatz zu make).
Eigentlich sollte man die Dateien nicht lesen müssen, der Aufruf von --help sollte reichen.
5.) Das dass fertige rpm nicht dort gespeichert wird, wo man das Spec-File aufgerufen wird.
Wo man es findest steht am Ende des builds.
6.) Das unter bestimmten Umständen die rpmbuild-Umgebung nicht automatisch erstellt wird.
Und zwar unter welchen?
7.) Das die rpmbuild-Umgebung von mehr als einem Paket verwendet wird.
Gegenfrage: Woher soll man wissen, dass es bei make nicht so ist? Man kann sich immer ein Alleinstellungsmerkmal heraussuchen und behaupten, das sei kompliziert und das
Der Aufbau von einem Makefile ist in einem Satz erklärt:
Ziel: Quelle Befehl
Zweizeiliges Beispiel:
<snip> kochrezept.pdf: kochrezept.tex pdflatex kochrezept.tex <snap>
Meinst Du wirklich, jemand kann mit dieser Anleitung ein Makefile schreiben?
Befehl für den User: "make" - das war es. Er User/Entwickler hat eine valides Makefile.
Aber dahin muss er erst mal kommen. Merkst Du eigentlich, dass Du Äpfel mit Birnen vergleichst? Du vergleichst das *Schreiben* eines spec files mit dem *Aufruf* eines Makefiles.
Wenn Du etwas vergleichst, dann vergleiche bitte * Schreiben von Makefiles mit Schreiben von spec files und * Aufrufen von Make mit Aufrufen von rpmbuild.
Besten Dank, Christoph
Hi!
Christoph Wickert christoph.wickert@googlemail.com hat am 4. März 2012 um 22:25 geschrieben:
Am Sonntag, den 04.03.2012, 20:25 +0100 schrieb Olaf Radicke:
Guten Abend!
Michael Schwendt mschwendt@gmail.com hat am 4. März 2012 um 11:39 geschrieben:
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.
Erst mal nicht. Als User brauchst du maximal drei Befehle: "make" & "make install". Manchmal noch eine "configure".
Als rpmbuild-User musst du wissen:
rpmbuild ist auch kein Tool für Nutzer, sondern für Entwickler und Paket-Maintainer. Ein Nutzer braucht nur rpm zu kennen.
1.) Das du ein Tar-Archiv des Codes brauchst.
Nein, es gehen auch andere Archive oder einzelne Dateien.
2.) Das er an einer ganz bestimmten stelle abgelegt werden muss (die auf unterschiedlichen Distributionen unterschiedlich sein kann).
Zeig mir eine Distribution, auf der es nicht rpmbuild/SOURCES bzw. % _topdir/SOURCES ist.
Ubuntu will direkt unterhalb von root das rpmbuild-Verzeichnis aufbauen und möchte dafür root-Rechte.
Mittlerweile habe ich das umgebogen. Aber ich habe soviel rumgemurckst das ich nicht mehr genau die Details weiß.
Gruß
Olaf
de-users@lists.fedoraproject.org