Re: Wiki-Artikel über rpmbuild

Christoph Wickert <[email protected]> Wed, 14 Mar 2012 10:30:09 +0100
Newsgroups gmane.linux.redhat.fedora.german
Message-ID <[email protected]>
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. 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.

Und hast du wirklich alle Dateien from scratch geschrieben oder hast Du
dh-make verwendet?

> und nach drei Stunden, eine funktionierendes deb-Repos.

Also hast Du 2 Stunden gebraucht, um ein Debian-Repo zu erstellen?

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

Mir fallen bestimmt noch mehr Gründe ein, aber ich belasse es mal dabei
und wende mich wieder meiner Arbeit zu - dem Bau von Debian-Paketen. :(

Beste Grüße,
Christoph

--
de-users mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/de-users