Re: Wiki-Artikel über rpmbuild

[Olaf Radicke]

Guten Abend!

Michael Schwendt <mschwendt at 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