Guten Abend! Michael Schwendt <mschwendt(a)gmail.com&gt; hat am 4. März 2012 um 11:39 geschrieben: 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. Gut, dann lass uns den Weg gehen, wie du meinst, das es sein muss... 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. 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