de-users March 2012

de-users@lists.stg.fedoraproject.org

4 participants
4 discussions

Re: Wiki-Artikel über rpmbuild
by Olaf Radicke 16 Mar '12

16 Mar '12

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

2 1

Wiki-Artikel über rpmbuild
by Olaf Radicke 14 Mar '12

14 Mar '12

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

4 31

Re: Wiki-Artikel über rpmbuild
by Olaf Radicke 05 Mar '12

05 Mar '12

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

3 6

Re: Re: Wiki-Artikel über rpmbuild
by Simon A. Erat 02 Mar '12

02 Mar '12

> > > 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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

de-users March 2012