• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[per RPM gelöst] tar.gz aus "make install" erzeugen

abgdf

Guru
LUH 3417 schrieb:
Wenn man/frau das mit dem rpmbuild mal kapiert hat, macht das richtig Spaß.
Ist halt die Frage, ob Du, wenn Du von einem Source-Code, der kompiliert, nur schnell mal ein rpm-file haben willst, jedesmal Lust hast, ein so langes spec-file zu schreiben.
 
OP
A

Anonymous

Gast
abgdf schrieb:
Ist halt die Frage, ob Du, wenn Du von einem Source-Code, der kompiliert, nur schnell mal ein rpm-file haben willst, jedesmal Lust hast, ein so langes spec-file zu schreiben.
Wann bekommt man(n) denn dazu schon mal Gelegenheit,
  • # man braucht das Paket in einer anderen Konfiguration
    # man will/muss irgendwelche Patche selbst einbringen
    # man braucht eine spezielle Version
    # man braucht ein Paket das entweder statisch gelinkt oder gegen spezielle Libraries gelinkt ist.
    # man braucht ein Paket das nirgends für die Distribution zu finden ist.
in 99% dieser Fälle in denen du den Quellcode nicht selbst neu geschrieben hast brauchst du das Specfile gar nicht neu erfinden, da brauchbare Spec Files dafür recht schnell zu finden sind und du dort wenn überhaupt nur kleinere Änderungen vornehmen musst. Das ist mit Sicherheit schneller als dir bei checkInstall erst noch eine Beschreibung für das Paket auszudenken, eventuelle Abhängigkeiten herauszusuchen und dann dort alles manuell bei jedem Versuch eingeben darfst oder dir eine überlange Befehlszeile selbst erstellen musst.

Müssen bei der Installation des Pakete noch spezielle pre oder post Dinge ausgeführt werden, (zB. Dienst stoppen/starte, globale Konfigurationen erstellen/anpasse/sichern ...... viel Spaß mit checkinstall. checkinstall ohne jede Menge Optionen und zusätzlich als Option trotzdem auch noch das Specfile kann es nicht viel mehr als als ein Paket erstellten und damit Verzeichnisse/Links erstellen, Dateien kopieren und Zugriffsrechte setzen. Solange du solche Pre/Post Dinge nicht selbst zum Paket erst noch selbst erfunden oder neu erstellt hast, sind diese Arbeiten in der als Vorlage benutzten Specfile in der Regel schon alle fix und fertig und schon alle berücksichtigt und mit eingearbeitet.

Die auffindbaren Specfiles haben oft auch schon die notwendige Konfigurationen und Anpassungen für das Erstellen bei verschiedenen Distributions Versionen und nicht selten auch für ganz verschiedene RPM-basierende Distributionen. Und bei der Ausführung von rpmbuild und vorgefertigten Specfiles sieht man oft schon frühzeitig wo es klemmt und braucht nicht erst lange zu versuchen die Logs von configure zu interpretieren um herauszufinden welches Develpaket man nun noch installieren muss, damit das kompilieren endlich funktioniert. Auch wenn bei etwas komplizierteren Paketen bei configure noch eine oder zwei Hände voll von Optionen mitgegeben werden müssen, damit am Ende das Programm auch wirklich die Features hat die erwartet werden, ist man mit einer fertigen Spec klar im Vorteil. Und das Ganze ist mit der Specfile zu jedem Zeitpunkt später jederzeit 1 zu 1 reproduzierbar, wenn also in einem halben Jahr noch ein Patch dazu kommt .... die funktionierende Specfile ist noch auf der Kiste oder im Quellpaket und damit ein Paket mit einer höheren Releasenummer und dem neuem Patch mit ganz wenig Aufwand und in kürzester Zeit erstellt.

Es gibt wohl massenweise Vorteile mit rpmbuild und Specfiles zu arbeiten. Schon mal probiert ein RPM Paket zu erstellen das vorher nicht mit make kompiliert wird ;) Sciptesammlung, Perl, Java, Python, PHP, DB-Profile ..... rpmbuild kann das und die Specfile ist Bauplan und Konfiguration dazu, Muss man nicht alles wissen oder beherrschen, aber deshalb muss man trotzdem nicht jedes mal das Rad immer wieder neu erfinden und eine eignen neue Spec von Grund auf neu erfinden. Und noch einen zumindest für mich gewichtigen Grund gegen checkinstall
checkinstall(8) schrieb:
Note that for most useful actions, checkinstall must be run as root.

robi
 

abgdf

Guru
robi schrieb:
Wann bekommt man(n) denn dazu schon mal Gelegenheit,
  • # man braucht ein Paket das nirgends für die Distribution zu finden ist.
Genau, und das ist gar nicht so selten, deshalb gibt's ja auch Packman, wo man dann noch interessante Pakete findet, die nicht in der offiziellen Distribution sind.
Es kommt aber auch vor, daß die Packman-Versionen nicht so sind, wie man sie möchte, dann muß man selbst kompilieren. Oder das Programm ist nichtmal bei Packman. Hier ein paar Programme, für die ich mit checkinstall eigene rpms gebaut hab'. Einige sind recht empfehlenswert:
aktuellen Mplayer, und, und, und. Ohne diese Programme würde mein Linux erheblich weniger Spaß machen.
robi schrieb:
Müssen bei der Installation des Pakete noch spezielle pre oder post Dinge ausgeführt werden, (zB. Dienst stoppen/starte, globale Konfigurationen erstellen/anpasse/sichern ...... viel Spaß mit checkinstall. checkinstall ohne jede Menge Optionen und zusätzlich als Option trotzdem auch noch das Specfile kann es nicht viel mehr als als ein Paket erstellten und damit Verzeichnisse/Links erstellen, Dateien kopieren und Zugriffsrechte setzen. Solange du solche Pre/Post Dinge nicht selbst zum Paket erst noch selbst erfunden oder neu erstellt hast, sind diese Arbeiten in der als Vorlage benutzten Specfile in der Regel schon alle fix und fertig und schon alle berücksichtigt und mit eingearbeitet.
Mag sein, bei manchen komplizierteren Kompiliervorgängen strecke ich auch einfach die Segel, wenn's nicht geht. Meistens sind die Pre/Post Dinge aber in den Optionen von "./configure" auszumachen, denke ich.
robi schrieb:
Und noch einen zumindest für mich gewichtigen Grund gegen checkinstall
checkinstall(8) schrieb:
Note that for most useful actions, checkinstall must be run as root.
Das dürfte daran liegen, daß auch "make install" meist nur als root geht. Spricht für mich ebensowenig gegen checkinstall wie gegen "make install".
Ich verwende checkinstall schon seit SuSE 8.1. Wenn es da nennenswerte Sicherheitsrisiken gäbe, hätte im Laufe der Zeit sicher schon jemand darüber berichtet.
 
Oben