1:25 p.m.
Guten Abend!
Michael Schwendt <mschwendt(a)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
2:47 p.m.
New subject: Wiki-Artikel über rpmbuild
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?
3:33 p.m.
New subject: Wiki-Artikel über rpmbuild
Hi!
Michael Schwendt <mschwendt(a)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
4:07 p.m.
New subject: Wiki-Artikel über rpmbuild
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)"
2:57 a.m.
New subject: Wiki-Artikel über rpmbuild
Michael Schwendt <mschwendt(a)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
3:25 p.m.
New subject: Wiki-Artikel über rpmbuild
Am Sonntag, den 04.03.2012, 20:25 +0100 schrieb Olaf Radicke:
Guten Abend!
Michael Schwendt <mschwendt(a)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
3:05 a.m.
New subject: Wiki-Artikel über rpmbuild
Hi!
Christoph Wickert <christoph.wickert(a)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(a)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
4440
days inactive
4441
days old
de-users@lists.fedoraproject.org
6 comments
3 participants
participants (3)
-
Christoph Wickert -
Michael Schwendt -
Olaf Radicke