Re: Wiki-Artikel über rpmbuild

[Olaf Radicke]

Hi!

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

Wiki-Artikel über rpmbuild

[Michael Schwendt]

On Fri, 16 Mar 2012 22:01:37 +0100 (CET), OR (Olaf) wrote:
> Christoph Wickert 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
> <> hat am 4. März 2012 um 23:07 schon gegangen ist.
> Egal, spitzfindige Nebensächlichkeiten. Gleiten wir nicht in fruchtlose
> Meta-Diskussionen ab.

Äh? Wie soll es mir schon gegangen sein? Ich habe per Zitat belegt, wie Du
die allgemeine Behauptung aufgestellt hast, nach einer Woche sei man
make-Guru.

Sowas löst beim Lesen Erstaunen aus. Falls man daraus keine Rückschlüsse
auf Dein Know-How bzgl. Make ziehen sollte, gewöhne Dir bitte an, weniger
Interpretationsfreiheit zu lassen. Es bleibt eigentlich nur der Ausweg,
daß Du Dich noch nicht eine Woche mit Make beschäftigt hast, um noch kein
Guru zu sein. Oder nicht intensiv genug usw.usf., aber wie kämst Du dann
auf die Dauer "eine Woche"?

Christoph hat dabei aus einer Woche einen Tag gemacht. Das macht die
Behauptung natürlich noch extremer, aber das Prinzip bleibt gleich.
Dein Vergleich vom Lernaufwand zu Make und rpmbuild ist komisch.
> http://de.wikibooks.org/wiki/Linux-Kompendium:_RPM-Pakete_mit_GNU_Make
> prefix=/usr/bin/

Auch die Eigenwilligkeit bleibt erstaunlich.
prefix ist entweder /usr/local oder /usr, andernfalls lassen sich
andere Pfade nicht davon ableiten.
>     chmod uoa+x $(DESTDIR)$(prefix)$(PROGNAME).sh
>     chmod uoa+x $(DESTDIR)$(PREFIX)$(PROGNAME).sh

Da wurde vergessen, eine Zeile zu löschen.
> dist-tar:
>        [ -d ./$(PROGNAME)-$(VERSION) ] ||  mkdir ./$(PROGNAME)-$(VERSION) 
>        cp -r ./src ./$(PROGNAME)-$(VERSION)/
>        cp ./Makefile ./$(PROGNAME)-$(VERSION)
>        cp $(PROGNAME).spec ./$(PROGNAME)-$(VERSION)/$(PROGNAME)-$(VERSION).spec
>        tar -cvzf $(ARCHIV) $(PROGNAME)-$(VERSION)
>        rm -rvf ./rpm-uebung-$(VERSION)

Warum verwendest Du fast überall ein explizites ./ Präfix, aber dann doch
nicht überall?
> Egal, spitzfindige Nebensächlichkeiten. Gleiten wir nicht in fruchtlose
> Meta-Diskussionen ab.

Wohl war, wohl war. Es steht Dir frei, nicht alles in Deinen Antworten zu
kommentieren bzw. zu bewerten, besonders nicht, wenn Du mit Deiner Sicht
stark divergierst. Picke Dir einfach heraus, was Du für brauchbar hältst.

;)