Re: Wiki-Artikel über rpmbuild

[Olaf Radicke]

Hi!

Christoph Wickert <christoph.wickert at 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 at 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