Re: Wiki-Artikel über rpmbuild
by Olaf Radicke
Hi!
Christoph Wickert <christoph.wickert(a)googlemail.com> hat am 14. März 2012 um
10:30 geschrieben:
> 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.
Zitiere mich wörtlich! Dann wird dir dein Verständnisfehler oder dein
lückenhaftes Gedächtnis bewusst. So wie es Michael Schwendt
<mschwendt(a)gmail.com> hat am 4. März 2012 um 23:07 schon gegangen ist.
Egal, spitzfindige Nebensächlichkeiten. Gleiten wir nicht in fruchtlose
Meta-Diskussionen ab.
> 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.
Die Ausführungen verstehe ich nicht. Das Wechselspiel zwischen Makefile
und dpkg ist ein völlig anderes als bei rpm. Und das beschreibst du
ja unten selber. Also was soll mir da ein Vorteil verschafft haben?
> Und hast du wirklich alle Dateien from scratch geschrieben oder hast Du
> dh-make verwendet?
Nein, dpkg und ein völlig neues Makefile. Es handelt sich um ein
anderes Projekt. Vom Plot her aber genauso simpel.
> > und nach drei Stunden, eine funktionierendes deb-Repos.
>
> Also hast Du 2 Stunden gebraucht, um ein Debian-Repo zu erstellen?
Ja, ich musste erst noch das Wechselspiel zwischen apt-get-config
und der Struktur des Repos verstehen. Bei den RPMs habe ich nichts
mit den Repos zu tun. Die werden bei uns mit Spacewalk verteilt.
Und den füttert ein anderer.
> > 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.
Ich würde sagen, das sind alles Punkte die für ein Distributor von
Bedeutung sind. Als Entwickler kenne ich selten die Umgebung meines
Programms im Detail. Für mich ist das Zielsystem fast so was wie eine
"black box". Wenn sich mein Programm auf Distri-A mit einem anderen
Programm in die Quere kommt, muss das bei Distrie-B nicht sein. Beispiel:
Das Apache-Paket kann "apache", "apache2", "httpd" oder ganz anders
heißen. Der Maintainer einer Distri weiß wie es heißt. Vielleicht
bestimmt er sogar darüber wie es heißt...
Wenn ich inhouse programmiere wird das Thema Sicherheit
und Integrität auf anderen Wegen gewährleistet. Wenn ich es verteile
müssen sich die User auf das ssl-cert des Server verlassen.
Gruß
Olaf
12 years, 1 month
- 2
- 1
Wiki-Artikel über rpmbuild
by Olaf Radicke
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
12 years, 1 month
- 4
- 31
Re: Wiki-Artikel über rpmbuild
by 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:
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
12 years, 1 month
- 3
- 6
Re: Re: Wiki-Artikel über rpmbuild
by Simon A. Erat
>
>
> 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
>
> Sers
Bin zwar selbst noch im lern-process mit dem rpmbuild, funktioniert aber
soweit ich das will (bisher wollte).
Ob es sich lohnt mehrere spec files zu haben, ist schwer zu sagen.
Was es aber sicherlich leichter macht, ist ein scriptfile vor dem rpmbuild
aufzurufen, welches dann die entrechenden änderungen durchführt.
In meinem Fall führt es das specfile mit dem changelog zusammen, generiert
den tarball, und kopiert diesen in den rpmbuild/SOURCES ordner.
Dann wird das generierte specfile via rpmbuild aufgerufen.
Bei einem grössen project müsste das specfile vlt in mehrere teile
gesplitet werden, so das änderungen nur einmal gemacht werden mussen.
Sollte aber theoretisch vermeidbar sein.
Hab mal mein script zur ansicht hochgeladen
http://sea.hostingsociety.com/sc/dev.sc
Hoffe das hilft weiter.
Grüsse ins Wochenende ;)
Simon
--
Simon A. Erat (sea)
Switzerland
12 years, 1 month
- 1
- 0
- ← Newer
- 1
- Older →