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